Nyári szünet

Pakolás, kapkodás ezerrel. Holnap hajnalban indulunk és csak valamikor júliusban leszek ismét gépközelben.
Szurkoljatok, mert délután megint elkapott a gyomorfájós roham, így valószínűleg egy alvás nélküli, zuhany alatt töltött éjszaka után fogok vezetni.

Azért tudok időzíteni, nem?

Vákum

Csak szólok. Ha valaki késő délután környékén a Népligetben járt és észlelte, hogy elfogyott a parkban a levegő… nos, az én voltam.
Miután a térdem miatt nem megy a bringa, úgy döntöttem, hogy futással sanyargatom tovább magam.
Ember… kurvára nem megy ez nekem… Ehhez a sporthoz soha nem volt affinitásom.
Meglátjuk, ki fog nyerni.

XL

Megmondom, mit utálok legjobban a kínai ruhákban: az idióta méretezést. Ha azt írják rá, hogy XL, akkor az kb. M-es… ha azt, hogy XXL, akkor az L-es és ha azt, hogy XXXL, nos, az az XL-es. Gondolom én, mert ilyet viszont már nem lehet kapni a mindenféle gigaszatócsoknál (Tesco, Auchan, Cora).
Ja, hogy miért vásárolok ruhát ilyen helyeken: azért, mert a belvárosban a lenvászon cuccokat aranyárban adják, én viszont mindenképpen szerettem volna egy lenvászon halásznadrágot. (A bermudát utálom, a hosszúnadrág meg erős lenne a dalmát kánikulában.)
Ma sikerült végre normális számozású halásznadrágokat találnom – és volt is köztük rámvaló. Roppant sajnálatosan csak barbirózsaszín és hányásbarna színekből állt a választék.

Szóval most van egy gyönyörű rózsaszín halásznadrágom.
Otthon úgy éreztem magam benne, mintha én lennék Miss Garrison.

42


Állítólag az élet értelme.
Remélem, nem sok köze van azokhoz, amiket éjszaka gondoltam, mert akkor régen rossz.

Dióhéjban.
Voltam ugye természetgyógyásznál, közölte, hogy a gyomrom nem bírja a fehérjét, annak utóemésztése okozza a belekben azt a kínzó éjszakai fájdalmat. Tíz napos szigorú böjtöt javasolt, utána pedig a fehérjetartalmú ételek kerülését. Végigcsináltam a koplalást, majd tegnap végre elkezdtem normálisan enni. Mértékletesen fogyasztottam, egy gramm fehérjét nem ettem – erre éjszaka olyan hosszú és erős fájdalmaim voltak, mint valamikor nagyon régen. Ha ehhez hozzászámítom, hogy – valószínűleg a legyengült immunrendszer miatt – bekaptam egy náthát és taknyom-nyálam összefolyik, akkor lassan el lehet képzelni a hangulatomat.

De félre a negatív hullámokkal, van azért minek örülni: Nejt elengedték szerdáról, így egy nappal korábban tudunk Horvátországba utazni és ki tudjuk kerülni a 22-ei nemzeti ünnep generálta forgalmat. Igaz, így lerövidült az autó szervizelésére fordítható idő, de majd kapkodunk.
Másfelől pedig azt hiszem, örülni kellene a születésnapomnak is. Enyhe kellemetlenség, hogy még a böjtidőszak alatt kértem Nejt, hogy süssön egy jó nagy kedvenctortát – gyümölcsös joghurttorta – és ebből, az éjszakai cirkusz miatt, nem biztos, hogy merek majd enni.

A kép egyébként azt ábrázolja, amint születésnapi ajándékomat szerelem fel éppen. (Na, ja. Köztudott, hogy általában olyan ajándékokat kérek, amelyekkel szopni lehet.)
Tehát az ajándék egy pár Continental Grand Prix 4000 külső gumi. Mondhatni, jelentősen megnőtt a bringa értéke. Az új gumi egyrészt gyorsabb, másrészt fantasztikus TPI értéke van. (TPI: thread per inch, ezzel mérik a defektállóságot. A régi gumié olyan 66 körül volt, ez a beszálló magasság az országuti gépek között. Kaptam is a defekteket, két kézzel. A 120 már egész jó értéknek számít. A mostanié az egészen fantasztikus 330-as értéket tudja, emellett van benne még egy speciális Vectran réteg. Ezzel szvsz letaszítja a korábbi defektállósági bajnokot (TPI280), még akkor is, ha a Continental máshogy számítja a TPI értéket.)
Az örömöt itt is árnyalja, hogy a térdem nem igazán akar javulni – és a gyógyszerek sem az igaziak. Elkezdtem szedni azokat, de egy hét után feladtam – annyira fájt tőlük a gyomrom, mint az istennyila. Megnéztem a manuálokat, szinte mindegyiken rajta volt, hogy gyomorégést, fekélyesedést okoznak. Az orvos szerint fél évig kell szedni. Kösz.)
Azért nyomtam ma egy rövid tízkilométeres menetet, öröm repülni most a géppel. Szomorú, hogy esélyt sem látok, hogy valamikor még nagy túrákra mehessek.

Szóval ilyen felemásan.
Elvagyok.

Két számjegy


zony apám le is fogy
mint a vöcsök nem et
mást csakis répát 80
ra 110-ról! és 95 tá
ján megpillantottam
a faszom! nagy érzés

Békés Pál: Lakótelepi mítoszok

Rossz hírem van, fiúk. Kiléptem.
Valószínűleg ideiglenes jelleggel, de kicsúsztam a Mázsa Klubból.

Azért ideiglenes, mert a méregtelenítés melléktermékeként a víz ment el – és az ilyesmi pillanatok alatt vissza fog jönni. De akkor is jó érzés volt rövid időre lemerülni.

Filmben élni

Az előző vásárlás mellékterméke, hogy amíg sorbaálltam, azalatt leemeltem a kínálópultról magamnak is egy mp3 lejátszót. Nem kell valami nagy dologra gondolni, ez egy 6900 forintos vacak, memória nélkül. (SD kártyás… az meg van otthon bőven.)
Eddig meglehetősen elzárkóztam a hordozható mp3 lejátszók elől, de ennek már nem bírtam ellenállni. Úgyis tele vagyok hangoskönyvekkel, naponta több, mint egy órát utazok metrón… miért ne kombinálnám ezeket össze?
Nos, az első tapasztalatok nem túl kellemesek. Annyira hangos az a nyomorult metró, hogy teljes hangerőn sem lehet tisztán hallani az angol szöveget.
De nem is erről akarok írni. Ma nemcsak a metrón hallgattam, hanem egész úton a fülemben felejtettem a dugót, szöveg helyett pedig zenét raktam be. Eszméletlen élmény volt. Úgy éreztem magam, mintha egy filmbe kerültem volna. Történtek körülöttem a dolgok, buszra fel, aluljárón át, metróra le-fel, buszra fel – és közben végig szólt az aláfestő zene. Eleinte Alvin és a Mókusok, később Timurlenk. Hihetetlenül illett a zene a tömegközlekedéshez. Nagyon élveztem.
Mondjuk azt nem tudom, mennyire hallatszott ki a zene… de valamennyire biztosan, mert hazafelé a metrón mellettem ülő nyanya orra érezhetően emelkedett percről-percre egyre magasabbra. Különösen a Szükségem van rád alatt vörösödött a feje. Gondoltam, elmagyarázom neki, hogy ez csak paródia, de másfél másodperc után letettem róla; nem úgy nézett ki, mint aki ismeri az irónia szó jelentését.

Durva teszt

Visszakaptam az autót és mivel kevés időm van tesztelni, ma kocsival mentem munkába.

A puszta tények:

  • Kispesten lakom, Újpesten dolgozom, a távolság 20 km.
  • Utazási idő kerékpárral: 65 perc.
  • Utazási idő tömegközlekedéssel: 60 perc.
  • Utazási idő autóval: 118 perc.

És ez is csak úgy, hogy Zuglónál eluntam, lecsűrtem a körútról a susnyásba és kőbányai, kispesti rejtekutakon értem haza. Közben folyamatosan figyeltem több rádióban is a pesti közlekedési híreket, de sehol sem említették meg a körutat. Ebből gondolom, hogy ez teljesen megszokott lehet ilyentájt.
A térdem ismét begyulladt a sok kuplungolástól.

Soha többet. Istenbizony.

A misztikus public folder replikáció III.


Az előző részekben szó esett a public folderek felépítéséről, részletesen leírtam egy egyszerű replikációs folyamatot és alaposan belementem abba, hogy milyen mechanizmusok támogatják az atombiztos multimaster replikációt.
Jelen írásban viszont inkább arra térnék ki, mi van akkor, ha valami mégsem működik annyira biztosan? A gyors válasz könnyű: akkor a replikáció betonbiztosan nem működik.
A legegyszerűbb megoldás, ha néhány konkrét eseten keresztül mutatom be ezt a nemműködést.

IV Tipikus problémák és megoldások

A címben első ránézésre van egy kis barokkos túlzás. A tipikus probléma ugyanis úgy néz ki, hogy nem működik a public folder replikáció. És itt meg is szokott állni a tudomány. Nem is csoda – a folyamat mélyebb ismerete nélkül az adminisztrátor leginkább csak hadonászik fakardjával a sötétben.

Nézzük, milyen eszközökre lesz szükségünk a megoldási folyamatban:

  • Eventlog, applikációs log.
  • Message tracking center.
  • ADSIedit.
  • ArchiveSink.
  • Józan ész.

Különösen az utóbbi fontosságát nem győzöm hangsúlyozni. A többi simán megvásárolható a boltban – de a tiszta gondolkodás nem található egyik polcon sem. Nevelgetni kell.

Az első, józan észhez kötődő megjegyzés: mindig pontosan legyünk tisztában vele, hogy hol vagyunk. Multimaster replikációnál talán ez a legfontosabb kiindulási pont. Tudni kell, melyik szerveren változtatunk és mely szervereken várjuk, hogy a változás – a replikáció révén – megjelenjen. Az Exchange System Manager-ben állítható, hogy melyik Exchange szerveren lévő public foldert támadjuk be. (Connect to… opció)

5. ábra A vizsgálandó Exchange szerver kiválasztása

Ha kliens oldalról piszkálódunk, akkor kiindulhatunk abból, hogy első körben azt a replikát fogjuk elérni, mely azon a szerveren van, ahol a postafiókunk. Amennyiben azon a szerveren pont nincs replika, akkor valószínűleg azt a szervert fogjuk elérni, amelyiken van replika és egy site-on van a postafiókunkat tartalmazó szerverrel. Habár létezik tool ennek pontos kiderítésére (MFCMAPI), de a használata nem nevezhető egyszerűnek. (Ez a segédeszköz az Information Store-ban tárolt paramétereit mutatja meg az egyes foldereknek. Jelen esetben a PR_REPLICA_SERVER paraméter tartalma érdekelhet minket.)
Ejtsünk még pár szót az applikációs logról. Alaphelyzetben az Exchange szerver nem túl bőbeszédű. Ha azt szeretnénk, hogy megeredjen a nyelve, fel kell emelni a logolás szintjét. Ezt megtehetjük a grafikus felületen vagy a registry-n keresztül. Nyilván van valami különbség a kettő között: a grafikus felületen beállítható maximum paraméter 5-ös erősséget takar, míg a registry-n keresztül beállíthatjuk az abszolút legerősebb logolási szintet, a 7-est.
Még azt kell eldöntenünk, melyik paraméteren állítsunk erősséget. Habár a Replication Errors paraméter nagyon illegeti magát, gyakorlati haszna nincs. Válasszuk helyette a Replication Incoming és a Replication Outgoing paramétereket; becsületszóra jobban járunk velük.

6. ábra Logolási erősség állítása grafikus felületről

7. ábra Logolási erősség állítása a registry-ben

Érdemes megfigyelni, hogy a 6. ábrán bekattintott Maximum erősség a 7. ábra szerint egyáltalán nem a maximum.

És most akkor jöjjenek a tipikus problémák.

1 A szerver nem publikálja a változásokat

Szokásos alaphelyzet. Jön Béla és módosít egy nyilvános mappa elemet – mert Béla már csak ilyen. Csakhogy Jenőnél a változás nem jelenik meg.
Induljunk el a változás forrásától. Első körben nézzük meg, azon a szerveren, amelyen a módosítás történt, be van-e kapcsolva a public folder replikáció. (A replikáció időzítését a 4. ábrán látható panelen tudjuk megnézni.) Az ‘always run’ érték jelenti a 15 percet. A legtöbbször egyébként nem folder szinten szokták hangolni a replikációs időzítéseket, hanem store szinten.
Amennyiben be van kapcsolva, akkor emeljük fel az események logolási szintjét a korábban említett módon és változtassunk meg egy újabb elemet. Most jön 15 perc dartsozás. (Alternatívaként lehet a képernyőt is bámulni üveges szemmel.) Ha nem találunk az applikációs logban 0x4 vagy hierarchia változtatás esetén 0x2 bejegyzést, akkor gáz van – a szerver nem publikálja, hogy rajta változtatás történt. Nagy valószínűséggel a PFRA nem indult el – és ez bizony nagyon nem jó hír. Általában ez az eset mixed módú organizációkban fordul elő, ahol még vannak 5.5 szerverek is. (Egy ilyen esettel foglalkozik pl. a 272999 KB cikk.) Ugyanezt a jelenséget tapasztaljuk, ha az 5.5 – 2000/2003 rendszerek között nem működik megfelelően a legacyDN – SID konverzió. (Ilyen eset lehetséges, ha a konverzió során ugyanaz a SID generálódott le két különböző felhasználónak. Értelemszerűen, ezt manuálisan kell korrigálni.)

2 Tényleg a szükséges szervernek lett elküldve a replikációs csomag?

Folytassuk az előző esetet. Tegyük fel, hogy 15 percen belül megtaláltuk a 0x2/0x4 bejegyzést az applikációs logban – tehát a szerver elküldte a replikációs csomagot. Kérdés, hogy hová? Ugye az alap probléma, hogy Jenő szerverén nem látszik a változás – azaz a szerver nem kapja meg a csomagot. Ez klasszikus levéltovábbítási probléma – úgy is kell megoldani.
Ilyenkor vesszük elő a Message Tracking Centert. Jó tudni, hogy a replikációs üzeneteket a PFRA-k úgy küldözgetik egymásnak, hogy mind a feladó, mind a címzett az adott szerver Public Folder Store szolgáltatása. Ezek smtp címei pedig a következőképpen generálódnak: <servername>-IS@<domain.name>; azaz pl. Clack1-IS@cegnev.hu.
Mind a hiba oka, mind a konkrét megoldás sokféle lehet. Mindet nem áll szándékomban sorba venni, inkább leírok egy konkrét esetet a saját élményeimből. Clack1-n változtattunk public folder tartalmat, de a változás nem ment át Clack2-re. Applikációs log szerint a replikációs üzenet elment – és ugyanezt tapasztaltam a Message Tracking szerint is. Clack2 ennek ellenére már nem kapta meg a replikációs csomagot. Hirtelen ötlettől vezérelve elkezdtem másképp kérdezgetni a Message Tracking-et. Addig ugyanis úgy vizsgálódtam, hogy beírtam egy időintervallumot és ott látszott, hogy igen, az egyik IS elküldte a másiknak a levelet. Most beírtam a konkrét emailcímeket (lásd fent), és amikor a címzettére kerestem rá, akkor nem kaptam találatot.

Kis kitérő: az smtp cím érdekes állatfajta. A címzett címe szerepel egyfelől a borítékon, másfelől magában a levélben is. Az ‘okos’ levélmutogatók ezt a belső címet szokták mutatni, mondván, hogy ez való inkább emberi fogyasztásra. Sajnálatos módon a levéltovábbítás a borítékra írt cím alapján működik – legalábbis az első lépésben. (A reply… az egy más világ.)

Nos, ez történt itt is. A szép cím a levélben tényleg a távoli IS neve volt, de a borítékra nem került fel semmilyen cím sem – tehát a levelek elmentek a nagy fekete semmibe. Ez onnan derült ki, hogy elővettem az ADSIedit segédprogramot és megnéztem az Active Directory konfigurációs névterében, hogy a célzott szerver IS szolgáltatásán belül konkrétan mi a Public Folder Store smtp címe. Konkrétan üres volt.

8. ábra Public Folder Store smtp címének tárolási helye a címtárban

Miután beírtam a megfelelő címet és megvártam, hogy szétreplikálódjon, beindult a public folder replikáció is.

3 Eljutott-e odáig a csomag?

Ha Clack1 elküldte a replikációs csomagot és ténylegesen Clack2 smtp címét írta bele, de ennek ellenére Clack2 mégsem kapta meg azt (nem szerepel az applikációs logjában a 0x2/0x4 üzenet), akkor ott levéltovábbítási problémával állunk szemben. Belépett a levélelkapó manó az organizációba. Ilyenkor segíthet a Message Tracking, az ArchiveSink segédprogram, illetve az egyes konnektorok és egyáltalán az email routolás átnézése. (Ez utóbbiról már írtam egyszer egy részletesebb cikket.)

4 A fogadó szerver megkapja a replikációs csomagot, de nem történik semmi.

Egyre cifrább, mi? Clack2 megkapta a replikációs csomagot – a Message Tracking szerint – de az applikációs logja nem mutat semmit. (Nyilván itt is maximálisra állítottuk a két paraméter logolási szintjét.) Ilyenkor mi van?
Alapvetően két eset lehetséges.

Elképzelhető, hogy a szerveren korrupttá vált a Replication State táblázat.
Gyors ismétlés: ez egy olyan táblázat, melyben a szerver adminisztrálja az egyes replikációs csomagokat. Minden replikabeli foldernek külön sora van.
Simán előfordulhat, hogy egy sor kiesik a táblázatból. Ekkor, hiába szerepel Clack1 replika listájában, hogy Clack2-n is van a konkrét foldernek replikája, és hiába látszik ugyanez Clack2-n is a grafikus felületen, Clack2 a Replication State tábla alapján úgy érzi, hogy nála bizony nincs – és lepergeti magáról a replikációs csomagokat. Gyógyítani lehet a klasszikus kiszáll-beszáll módszerrel: eltávolítjuk a folder replika listájáról Clack2-t, majd újra visszarakjuk.
Azért létezik ennél cizelláltabb megoldás is, az isinteg programnak van egy olyan kapcsolója, hogy replstate. (Egész konkrétan lásd a 889331 KB cikkben.)

Nézzük a másik esetet.
Exchange2003 esetében képbe kerülhet egy jogosultsági problémára visszavezethető hibaforrás is. Az Exchange2003 ugyanis igényli, hogy a feladó szervernek meglegyen a Send As joga a fogadó szerver virtuális SMTP szerverén. Ellenkező esetben a fogadó szerver nem fogja tudni lejátszani a replikációs csomagot. Alaphelyzetben ez a jogosultság adott… de a jogosultságok arról híresek, hogy az adminisztrátorok elállítgatják. (Nem feltétlenül kell persze semmit sem elállítani: elég, ha a feladó szerver kikerül az Exchange Domain Servers csoportból.) Hogy cifrázzam a helyzetet, olyasmi is előfordulhat, hogy habár a jogosultságok léteznek, de a fogadó szerver Kerberos hiba miatt képtelen autentikáltatni a feladó szervert.

5 Tudja-e a PFRA, hogy hiányzik adata?

Honnan is tudná az a szerver? Emlékszünk rá, egy konkrét folder teljes CNset-je a státusz üzenetekben utazik. Ha kimarad egy változás, akkor bizony a szerver egész addig nem értesül a változtatásról, amíg ugyanabban a folderben nem következik be egy másik változás. (Eltekintve azon ritka esetektől, amikor módosítjuk a replika listát vagy visszatöltünk mentésből egy régebbi állapotot – illetve el nem telik 24 óra a legutóbbi változás óta.)
Arra is emlékszünk, hogy a hiányzó változás rákerül a szerver kívánságlistájára, majd a timeout letelése után a szerver elküldi a backfill igényt. (0x8) A kívánságlistát közvetlenül nem tudjuk olvasni, de ha meredt szemmel figyeljük az applikációs logot, akkor észrevehetjük a 0x8 üzeneteket. Ha van ilyenünk, akkor biztosak lehetünk benne, hogy a PFRA tudja, hogy valami hiányzik.
A módszer egyetlen hátránya, hogy kicsit sokat kell várni. Ha például egy másik site-on van egyedül megfelelő replika, akkor az első timeout 12 óra, a második 24 és a harmadik 48 óra. Ennyi még dartsból is sok.
Le lehet egyszerűsíteni a szituációt úgy, hogy rákényszerítjük a szervert arra, hogy vegye tudomásul a hiányzó változást. Ehhez természetesen különböző módszerekkel státusz információkkal kell bombáznunk.

  • Egyik lehetőség, hogy elmegyünk egy másik szerverre és megváltoztatunk valamit az illető folderben. Ilyenkor a replikációs csomagba belekerül a folder státusz információja is, tehát a lazsáló szerver biztos megkapja a szükséges információkat.
  • Van egy remekül eldugott opció, melynek segítségével kikényszeríthetjük a tartalom szinkronizálást.
  • 9. ábra Tartalomszinkronizálás kikényszerítése

    Ha itt azt mondjuk egy folderen állva, hogy Synchronize Content, akkor két dolog történik:

    1. A kijelölt szerver 0x20 (status request) csomagot küld a replikáknak.
    2. A kijelölt szerveren lenullázódik a backfill timeout.

    Ebből az első a lényeges most számunkra: az egyik szerverről kiadott status request ugyanis mellékesen tartalmazza a szerver által ismert státusz információt is – nekünk pedig pont az a célunk, hogy a távoli szerverhez eljussanak ezek az információk.
    Konkrétan: ha azt szeretnénk, hogy Clack2 megtudja, hogy nála hiányzik egy változás, akkor Clack1 megfelelő folderén kell megnyomni a Synchronize Content gombot. (És nagy ívben nem fog érdekelni minket, hogy Clack2 visszaküld majd egy 0x10 üzenetet.)

  • Ugyanezt a trükköt tudjuk eljátszani a Send Hierarchy / Send Contents opciókkal is.
  • 10. ábra Hierarchia replikáció kikényszerítése

    11. ábra Tartalom replikálásának kikényszerítése

    Ekkor ugyan backfill válaszokkal küldjük meg a célzott szervert, de jelen esetben ez mindegy; az a lényeg, hogy az státusz információkhoz jusson, azok pedig a backfill válaszokban is benne vannak.

  • Használhatjuk a korábban említett Replication Flag registry turkálást.

6 Ha tudja, akkor igényli is?

Miután jól kitömtük a szervert státusz információkkal, most már egész biztosan tudnia kell, hogy nem teljesen naprakészek a folderei. Kérdés, hogy ezután fog-e tenni valamit tudásbéli hiányosságainak leküzdésére?
Amit konkrétan szeretnénk látni, az az, hogy a szerver nekiáll a megfelelő replikákat tartalmazó szerverek felé 0x8 (backfill request) csomagokat küldeni. Ugyan várhatunk, hátha egyszer megjelenik az applikációs logban, de azért a timeout értékek meglehetősen ijesztőek. Jobb, ha akcióba lépünk. Az előző pontban szóba került egy módszer, a Synchronize Content. Megemlítettem, hogy ez mellékesen lenullázza a backfill timeout-ot is. Pont ez kell nekünk. Immár azon a szerveren, ahol hiányzik a tartalom, kiadunk egy Synchronize Content parancsot és egyből ki is kell menniük a 0x8 csomagoknak.

Mi van, ha mégsem mennek ki? Pontosabban valamerre kimennek, de pont a minket érintő csomagok nem jelennek meg? (Mi is érdekel minket? Van egy konkrét folder, amelyikben tudjuk, hogy nem frissül egy objektum. Tudjuk, hogy ennek mely szervereken vannak replikái – tehát szeretnénk olyan 0x8 csomagokat látni, melyek e replikák felé mennek és a kérdéses folder tartalmat igénylik.)
Ha ebbe az esetbe ütközünk, akkor jobb, ha tudjuk, hogy kivertük a biztosítékot. Van ugyanis egy ún. lassító mechanizmus a public folder replikációs folyamatban. (Én mondtam, hogy az Exchange fejlesztők nem kapkodó idegbetegek.) Ezt úgy hívják, hogy Outstanding Backfill Limit – és azt szabályozza, hogy a kívánságlista ne nőhessen a végtelenségig. Alaphelyzetben 50 elemet tartalmazhat. Természetesen ha egy backfill csomag beérkezett, akkor a PFRA kihúzza azt a listáról és bekerülhet helyére egy újabb. Viszont ha a szerver olyan csomagokat igényel, melyek már nincsenek meg egyik Exchange szerveren sem, vagy a szükséges Exchange szerver éppen elérhetetlen, akkor ez az ötven kívánság beragad és a többiek nem jutnak lehetőséghez.

Két dolgot tehetünk:

  • Nekiállunk dolgozni. Megnézzük az applikációs logban, hogy hová mennek a 0x8 csomagok és mit igényelnek. Aztán megpróbáljuk elérhetővé tennük számukra a szükséges változtatásokat.
  • Berugdossuk a dögöt az ágy alá. Registry piszkálással a fenti limit megnövelhető, egészen ötezerig. Ekkor viszont időszakonként komoly backfill viharokra számíthatunk, mely veszélybe sodorhatja az Exchange szerverek elérhetőségét.

7 Foglalkozik-e a többi szerver az igénnyel?

Az eddig leírtak alapján már nagyon könnyen nyomozhatunk. Láttuk, hogy az igénylő szerver elküldte a 0x8 backfill kéréseket.
Vizsgáljuk meg a megcélzott szerverek applikációs logját, hogy megkapták-e a csomagokat?
Ha megkapták, nézzük meg, válaszolnak-e rájuk. Ha igen, akkor azt kell látnunk, hogy megjelennek az applikációs logban a 0x80000002 illetve 0x80000004 backfill válasz üzenetek. (Értelemszerűen nem ugyanannyi válasz lesz, mint amennyi igény érkezett. Az igény azt mondja meg, hogy melyik változás kell neki. A válaszban meg megy a módosított elem – és ha a módosított elem nagyobb, mint a replikációs üzenet maximális engedélyezett mérete, akkor a PFRA több üzenetbe tördeli. Ugyanezért ne essünk kétségbe, ha a válasz nem egyből jelenik meg az igény fogadása után – elképzelhető, hogy sokat kell a csomag összeállításával bajlódnia a PFRA-nak.)

8 Megkapja-e a szerver az igényelt válaszokat?

Szinte már semmit nem kell írnom. A szokásos módon, az applikációs logok és a Message Tracking segítségével nyomon tudjuk követni, hogy mi történt a backfill válasz csomagokkal. Ha a szerver nem kapta meg, akkor levéltovábbítási problémánk van megint. Ha megkapta, de nem érvényesül a változás, akkor pedig a 4. pontban írtakkal állunk ismét szemben.

Nos, ennyi.
Remélhetőleg sikerült utat vágnom a dzsungelben.

Mi van még?
Az irodalom.
A cikk összeállításában sokat segített a Microsoft Technet Exchange szakkönyvtár és az Exchange csapat blogja. Mindkettő erősen ajánlott olvasmány.

A misztikus public folder replikáció II.


Az előző részben szó esett nagy általánosságban a public folderekről, felépítésükről és a public folder replikáció építőelemeiről. Leírtam, alaphelyzetben hogyan replikálódik egy elem, miután módosította őt Béla.
Ebben a részben elindulunk a dzsungel belsejébe. Vigyázat, túristaösvény csak az első pár méteren lesz.

III Kínzó kérdések

1. Mi történik akkor, ha egy szerver – a rajta tárolt adatokhoz képest – régebbi módosítást tartalmazó csomagot kap?

Tulajdonképpen nem is az a kérdés, hogy mi történik – sokkal inkább az, hogy hogyan derül ez ki? Mint korábban írtam, a replikáció nem időbélyeg alapú. A kulcsszereplő jelen esetben a Message State információk közül a predecessor change lista. Ebben van az összes olyan CN, mely valaha is hozzá volt rendelve az adott objektumhoz.

Nézzünk egy példát.

Legyen az objektum predecessor change listája a következő:

<guid -Clack1>-1210
<guid -Clack2>-6547
<guid -Clack1>-1068

Értelemszerűen ez mindegyik replikánál egyforma. Jön Béla és módosítja a Clack1 gépen lévő objektum nevét. Ekkor Clack1 predecessor change listája így fog kinézni:

<guid -Clack1>-1541
<guid -Clack1>-1210
<guid -Clack2>-6547
<guid -Clack1>-1068

Ezt a PFRA belecsomagolja a replikációs csomagba és elküldi Clack2-nek. Ő kicsomagolja és az összehasonlítás után észreveszi, hogy az őnála lévő predecessor lista részhalmaza az újonnan küldött listának, tehát az új lista a király.
Ha valamilyen baleset következtében régebbi módosítást kap meg, akkor azt fogja találni, hogy az új lista részhalmaza a nála lévő listának – kacag egy jóízűt és ignorálja a replikációs csomagot.

2. Mi történik ha egyszerre módosítják ugyanazt a – különböző replikákban létező – objektumot?

Jön Béla és kegyetlenül megint módosítja az előző objektumot. Igenám, de színre lép Jenő is, akit szintén ellenállhatatlan kényszer gyötör, hogy módosítsa ugyanazt az objektumot. Sajnálatosan Jenő postafiókja Clack2-n van. Ráadásul mindez azonos replikációs intervallumon belül történik meg.
Nézzük a példát:

Kiindulási állapot:

Clack1 Clack2
<guid -Clack1>-1210 <guid -Clack1>-1210
<guid -Clack2>-6547 <guid -Clack2>-6547
<guid -Clack1>-1068 <guid -Clack1>-1068

Béla módosít:

Clack1 Clack2
<guid -Clack1>-1541  
<guid -Clack1>-1210 <guid -Clack1>-1210
<guid -Clack2>-6547 <guid -Clack2>-6547
<guid -Clack1>-1068 <guid -Clack1>-1068

Jenő módosít:

Clack1 Clack2
  <guid -Clack2>-7124
<guid -Clack1>-1210 <guid -Clack1>-1210
<guid -Clack2>-6547 <guid -Clack2>-6547
<guid -Clack1>-1068 <guid -Clack1>-1068

Megtörténik a replikációs csomagok elküldése. Ezeket a predecessor change listákat kell összehasonlítaniuk a szervereknek:

Clack1 Clack2
<guid -Clack1>-1541 <guid -Clack2>-7124
<guid -Clack1>-1210 <guid -Clack1>-1210
<guid -Clack2>-6547 <guid -Clack2>-6547
<guid -Clack1>-1068 <guid -Clack1>-1068

Látható, hogy egyik sem részhalmaza a másiknak. Replikációs konfliktus keletkezett.
Mi alapján döntik el a PFRA-k, hogy melyik módosítás nyert? Aki azt mondja, hogy majd az időbélyeg dönt, azzal közlöm, hogy ugyan logikusan tetszik gondolkozni, de jelen esetben nincs szivar. A konfliktusnak ugyanis kifejezetten csalafinta feloldását fundálták ki az Exchange fejlesztők.
Maga a PFRA lép akcióba és küld egy ún. conflict message üzenetet Bélának és Jenőnek. Mindemellett a konkrét folder összes tulajdonosánál is bemószerolja őket. Sőt, az üzenetet bemásolja a public folderbe, ahol persze szétreplikálódik az összes szerverre, ahol létezik replikája. Majd ezek után angyali mosollyal kisétál a szobából és hagyja, hogy az érintettek ököljog alapján rendezzék a helyzetet.
(Hierarchia replikációs ütközésnél egy kicsit visszafogottabb a PFRA, ekkor csak a folder tulajdonosait értesíti.)

3 Mi történik, ha el lett lazsálva egy replikáció?

Eddig egy ideális világról beszéltünk. Clack1 észlelte a változást, elküldte a csomagot Clack2-nek, aki lelkesen frissítette is az objektumot. De mi van, ha pont arra jár a levélelkapó manó és a replikációs csomag nem érkezik meg? Ugye, tudjuk, Clack1 a csomag elküldésének pillanatában el is könyvelte, hogy Clack2 is módosított. Ő ugyan több értesítést nem fog küldeni. Clack2 meg elégedetten üldögél a fenekén, fogalma sincs, hogy neki módosítania kellett volna.
Pánikra nincs ok. (Az Exchange egyébként is a türelmes adminisztrátorok platformja.) Létezik egy mechanizmus, mely ezeket a lyukakat hivatott felderíteni. Az egyes szerverek PFRA szolgáltatásai időnként státusz információkkal bombázzák egymást – márpedig a státusz információk CNset-ekből állnak, azok meg CN értékekből. Ebből mindegyik PFRA ki tudja bogarászni, hogy megvan-e nála az összes módosítás, amely egy objektumot érintett. Ha talál olyat, amelyik nála nincs, akkor azt a módosítást felveszi a kívánságlistájára. Ez utóbbit backfill array-nek hívják.
De ne rohanjunk ennyire. Először járjuk körül, milyen esetekben is cserélnek státusz információkat az egyes szerverek?
Mikor kér egy public folder státusz információkat? (0x20, status request)

  • Egy folderhez hozzáadunk egy replikát… vagy ellenkezőleg, elveszünk tőle egyet.
  • Elindul egy új public folder store.
  • Visszatöltöttünk egy store-t backupból és felcsatoltuk.
  • Újraindítunk egy store-t, úgy, hogy bekattintjuk az ún Replication Flag értékeket a registry-ben. Ekkor a PFRA kéri az összes hierarchia státusz információkat és a nyilvántartása szerint hiányzó tartalom státusz információkat. (Részletesen lásd a 813629 KB cikkben.)
  • Újraindítunk egy store-t, úgy, hogy bekattintjuk az ún Enable Replication Messages On Startup értékeket a registry-ben. Ekkor a PFRA kéri az összes hierarchia státusz információkat és az összes tartalom státusz információkat. (Részletesen lásd a 321082 KB cikkben.)

És vajon mikor küld egy PFRA státusz információkat? (0x10, status message)

  • Minő meglepetés: ha valamelyik szervertől status request (0x20) kérést kapott.
  • Ha már huszonnégy órája nem érkezett frissítés egy folderhez. Ekkor az összes olyan szerver felé elmegy a státusz üzenet, amelyiken van replikája az adott foldernek.

Végül ne felejtsük el, hogy mindegyik replikációs csomagba bele van csomagolva a frissítésben érintett folder státusz információja.

Oké. Státusz információk jönnek-mennek, Clack2 fejéhez kap: Úristen, hiányzik egy konkrét CN számú frissítés!. Fel is veszi egyből a frissítést a kívánságlistájára. Mivel az Exchange programozók is ismerik azt a dalszöveget, hogy “sokkal jobb, ha úgy szerzed, hogy vágyol utána”, ezért nem elégítik ki egyből Clack2 kívánságát. Várnak. Nem is kispályások, a timeout értékek viszonylag magasak. Ha a megkívánt update olyan Exchange szerveren van, mely azonos site-on van az ígénylő Exchange szerverrel, akkor a timeout értékek sorban: 6/12/24 óra – ellenkező esetben 12/24/48 óra.
Nem mondom, hagytak időt bőven arra, hogy a hiányzó értékek esetleg maguktól is odataláljanak.

Kis kitérő. Háromfajta Exchange adminisztrátor van:

  • A legrosszabb típus, a türelmetlen versenyző. Össze-vissza kattogtat és dühöng, hogy miért nem történik semmi. Képtelen felfogni, hogy az Exchange időnként kifejezetten nagy holtidőkkel működő rendszer.
  • Egy fokkal jobb, aki üveges szemekkel bámul apatikusan a képernyőre, de legalább nem kattogtat. Neki ugyanis már van esélye arra, hogy eszébe is jut valami értelmes, nagyjából addigra, amikorra a változások is végighullámoznak a rendszeren.
  • A legérdekesebb az, hogy külső szemlélő számára az előző adminisztrátor és a profi között nem látszik semmi különbség. A profi is ugyanúgy üveges szemekkel ül a monitor előtt – de közben tudja, mi zajlik a háttérben: tisztában van vele, mire vár.

Vissza a száraz elmélethez. Clack2 tehát tudja, melyik CN számú upgrade hiányzik, felvette a kívánságlistára és letelt az első timeout (6/12 óra). A PFRA fogja magát és küld egy backfill request-et (0x8). Kinek? Ez bizony jó kérdés.
Imhol az algoritmus.

  • Clack2 készít egy listát azokról a szerverekről, ahol megtalálható az a replika, mely a kérdéses változáshoz tartozik.
  • A lista elemeit sorba rendezi, a következő szempontok szerint:
    • Működik-e a szerver?
    • Ki a preferred backfill server? (Nem szokott lenni.)
    • Mennyi a transzport költsége?
    • Milyen verziójú az illető Exchange szerver?
    • Hány igényelt változáshoz tartozó csomag található a szerveren?

Nem minden szempont bír azonos súllyal. Általában elmondható, hogy a transzport költsége mindent visz. Logikus, hiszen ha van frissítés az azonos site-on lévő Exchange szervereken, akkor először azoktól kell begyűjteni, még akkor is, ha azok csotrogány 5.5 szerverek.
Most már tulajdonképpen készen is vagyunk. Tudjuk, melyik csomag hiányzik. Tudjuk, melyik szerverről szerezhetjük be optimálisan. Elküldjük neki a backfill request-et (0x8) és meg is kapjuk a csomagot (0x80000002 v. 0x80000004).
Vagy nem. Ha nincs válasz, akkor a szervert úgy veszi a PFRA, hogy nem működik és újra összeállítja a listát. Persze közben a timeout értékek próbálkozásonként szépen nőnek – hasonlóan az Exchange admin ősz szakállához.

4 Mi történik replika hozzáadásakor, elvételekor?

Ez:

  1. Egy konkrét folderből csak egy példány létezik, Clack2 gépen.
  2. Clack1-n dolgozva az adminisztrátor hozzáadja Clack1-t a folder replika listájához.
  3. Clack1 küld egy hierarchia üzenetet Clack2-nek, aki szintén felveszi a replika listára Clack1-t.
  4. Clack1 küld egy status request-et (0x20) Clack2-nek.
  5. Clack2 visszaküld egy status üzenetet (0x10) Clack1-nak, benne a folderre vonatkozó státusz információkkal. (Full CNset.)
  6. Clack1 észreveszi, hogy egyik CN sincs meg nála. Felveszi az egész bagázst a kívánságlistájára.
  7. Letelik az első backfill timeout. Ha még mindig hiányzik a tartalom, Clack1 elkezdi küldözgetni a backfill igényeket (0x8).
  8. Clack2 szorgalmasan küldözgeti vissza a backfill válaszokat (0x80000002 v. 0x80000004).
  9. Clack1 kicsomagolja és lejátssza a módosításokat. Ezzel párhuzamosan törli a megadott számú változást a kívánságlistájáról.
  10. Amennyiben letelik a következő backfill timeout, Clack1 újra elküldi a backfill igényeket.
  11. Előbb-utóbb átkerül a kérdéses folder összes tartalma Clack1-re is.

Mint látható, ilyenkor a szerverek státusz információk segítségével derítik ki, hogy az új szerveren olyannyira hiányoznak a változtatások, hogy tulajdonképpen nincs is rajta semmi. Az összes tartalom átlapátolása ilyeténképp a backfill folyamat segítségével történik. Meg lehet saccolni a dinamikát.
Ebből következik egy gyakorlati tanács is. Ha egy konkrét foldert át szeretnénk migrálni egyik szerverről egy másikra, akkor először fel kell venni a folder replika listájára az új szervert, majd megvárni, amíg az új szerveren a Public Folder Instance listában megtalálható lesz a folder. Utána érdemes csak levenni a régi szervert a replika listáról.

5 Mi történik, ha úgy rakok át egy public folder tartalmat egyik szerverről a másikra, hogy a folder replika ablakában hozzáadom a listához az új szervert, leveszem a régit, majd törlöm a régi szerverről a komplett store-t?

Balhé.
Vizsgáljuk meg alaposabban, mi is játszódik le ilyenkor.
Egyáltalán nem meglepő módon, ha letörlök egy szervert a replika listáról, akkor a szerver nem szabadul meg pánikszerűen a tartalomtól. Ehelyett küld egy speciálisan preparált 0x20 status request-et az összes többi replikának. Ennek van böcsületes neve is, Replica Delete Pending Status Request-nek hívják és RDPSR-nek becézik. Ebben a csomagban van egy flag, amely jelzi, hogy a replika függőben lévő törlésben szenved. Ha a többiek megkapják ezt az üzenetet, akkor egy szintén speciális csomaggal válaszolnak. Ez egy különleges 0x10 csomag, melyet Replica Delete Pending Ack-nek hívnak. (A becenév kitalálása házi feladat.) Azt jelzi, hogy a megszűntetni kívánt replika által birtokolt CN változtatások megtalálhatók egy másik replikán is. (Nyilván csak akkor jön ilyen válasz, ha a változás tényleg létezik máshol.) Nna, ekkor törli csak a PFRA a tényleges tartalmat.
Tegyük fel, rossz napunk volt, türelmetlenek vagyunk, mint egy bespeedezett gepárd. Ahogy módosítottuk a replika listát, egyből megyünk is a megfelelő szerver public folderéhez és töröljük a store-t.
Nos, hacsak nem Exchange2003 Sp2 szerverünk van, akkor nagy valószínűséggel ezzel el is veszítettünk valamennyi nyilvános mappa tartalmat. A korábbi verziók ugyanis nem foglalkoznak azzal, hogy üres-e a Public Folder Instances lista a store törlése előtt. (Az Sp2-t is meg lehet erőszakolni, de az legalább figyelmeztet.)
(Van még egy másik különbség is. Az Sp2 előtti szerverek csak egyszer küldik ki az RDPSR-t, aztán várnak, akár az örökkévalóságig az RDPÁ-ra – persze közben a konkrét szerverről nem tűnnek el a folder példányok. Ilyenkor annyit lehetett tenni, hogy újra felvettük a szervert a replikák közé, majd ismét töröltük, ezzel generálva újabb RDPSR-t. Sp2 után gyakorlatilag óránként generálódik újabb RDPSR.)

Mára ennyit. Holnap újra jövök.

Öreg autó bizony vén autó

Tegnap szólt Nej, hogy jó két hete egyszer nem váltott vissza az automata váltó gyorsításkor, csak zörgött. Ránézésre nem egy nagy tragédia, azóta megy minden rendesen, de én egyből a fejemhez kaptam. Eddig kétszer kellett váltót cserélni a kocsiban és mindegyik eset valahogy így kezdődött. Ebben nem is az a 350e forint a durva, amennyibe a csere kerülne, hanem az, hogy nyolc nap múlva megyünk Horvátországba. Arra már nincs időm, hogy most váltót cseréltessek rajta, arra sincs időm, hogy a régóta tervezett automata->manuális átalakítást megcsináltassam – arra meg végképp nem lesz, hogy a régóta érő autócserét le tudjam zongorázni. (Amíg nem rendeződik a lakáshelyzet, egyébként sem akarunk új kocsira költeni.)
Viszont. Mivel maximum 5-600e forintért tudnám eladni, így ha pont Horvátországban romlik el, akkor tényleg egyszerűbb lesz berúgni az árokba, mert a hazaszállítás és a váltócsere már több, mint a kocsi értéke. Persze van esély, hogy kibírja, de azért a betervezett 2000 kilométer körüli távolság nem sok derűlátásra ad okot. A szállás természetesen már ki van fizetve.
Elbeszélgettem a szerelővel, ő is csak annyit tudott mondani, hogy használjuk sokat, ha hibás, legalább itthon derüljön ki. Amikor elővezettem, hogy hová megyünk, meggondolatlanul kibökte, hogy ő is pont arrafelé lesz akkortájt.
– De nem szerelek autót! – rémült meg hirtelen, amint látta, hogy felcsillan a szemem.

Futottam még egy kört, utánanéztem, van olyan, hogy Autóklub Exclusive Assistance biztosítás, pont az, amire szükségem van. Már majdnem meg is kötöttem, amikor kiderült, hogy a max korhatár 12 év – abból meg már kinőtt a kicsike.

Nos, így állunk. Miután a tavalyi egyik nyaralást szintén ez a kocsi vágta tönkre, a másikat az augusztusban beköszöntött október, most megint sanszunk van arra, hogy ne legyen nyugodt a pihenés. Remek bizonytalan döntés áll előttem: a legjobb esetben nem történik semmi, a többi esetben vagy bebukom az egyheti szállásdíjat vagy magát a kocsit.
Remek.

[Update]
Beszéltem a szerelővel, végülis bevállalta az átalakítást nyolc napon belülre. Ez 150e lesz, remekül fog mutatni az Excel táblában a nemrég elkövetett komplett gumicsere és futóműrendberakás 130ezres tétele mellett.
Egész pontosan tudom, milyen érzés szitával vizet hordani.

A misztikus public folder replikáció I.


Ez a hosszú írás eredetileg nem ide íródott, de aztán később úgy döntött, hogy visszajön Apucihoz. Pusztán a jobb olvashatóság érdekében szedtem darabokra, egyben valószínűleg igen durva lett volna.

Miről is lesz szó? A csapból évek óta folyik az Active Directory replikációjának boncolgatása. Viszont szó sem esik egy másik nagy replikációs témáról, a nyilvános mappák replikációjáról. Az AD replikáció multimaster replikáció, az adatbázis pedig egy JET alapú adatbázis. Ezzel szemben a public folder replikáció multimaster és JET alapú adatbázisok játszanak benne.

Nocsak. Akkor most ugyanarról beszélünk vagy sem?

Természetesen nem. Az egyik esetben az AD ldap adatbázisa replikálódik, a másik esetben az Exchange Information Store adatbázis egyik adatbázisa. Történelmi okokból a két replikáció működési mechanizmusa még csak véletlenül sem hasonlít egymásra.
Hogy még cifrább legyen a helyzet, a public folderek adatai egy kicsit össze is vannak keverve az adatbázisok között. De erről majd később. Most ugorjunk neki az első témának.

I. Általában a public folderekről

Gondolom, itt nincs túl sok szükség szószaporításra. Akinek volt már postafiókja Exchange szerveren – bármilyenen – és próbálta már azt MAPI kliensen keresztül elérni, pontosan tudja, miről beszélek.
Igen, a folder lista alján található nyilvános mappákról. Ezek egyfajta kollektív tárolóhelyek, mindenféle közösen használt anyagokat szoktak itt tárolni az egyes cégek. Láttam már itt céges telefonkönyvet e-mailbe ágyazott Excel tábla formájában, láttam már különböző szintű vállalati rendelettárat… és végtelen a fantázia szárnyalási tere, hogy mi mindent lehet még ide betenni.

Persze mi műszaki emberek vagyunk, minket sokkal jobban érdekel, hogy hogyan is tárolja mindezt az Exchange szerver. Nos, jelen esetben két különböző helyen tárolódnak adatok: egy részük az Active Directoryban helyezkedik el, más részük pedig az Information Store adatbázisaiban. Az első adatcsoporttal most nem szándékozom túl sokat foglalkozni, ezek az adatok jól érzik magukat a címtárban, boldogan használják annak replikációs szolgáltatásait, köszönik szépen. Ide tartoznak az egyes store-ok paraméterei és konkrét nyilvános mappák meglehetősen sok tulajdonsága is. Például amennyiben az egyes folderekhez smtp címet rendelünk, az a cím is a címtárban rögzül.

1. ábra Public folder smtp címe az Active Directory-ban

(Mondjuk egy pillanatra álljunk meg és gondolkodjunk el, hogyan is működik _egymás mellett_ a kétfajta replikáció: a címtáré és az Information Store-ban tárolt nyilvános mappákké. Megvan? Akkor várjunk egy kicsit, amíg elmúlik a szédülés.)

Jelen írás mindemellett azokra az adatokra fókuszál, melyek az Information Store adatbázisában helyezkednek el.

A legfontosabb, hogy tisztában legyünk az adatok tárolási formájával. Pongyolán fogalmazva, a JET tárolási forma lényege, hogy van egy adatbázis, amelyben ömlesztve találhatók mindenféle adatok és egy másik, ehhez kapcsolódó adatbázis, melyben tömérdek pointer mutat rá a másik adatbázis egyes adataira, értelmezhetővé téve azokat. Ezután egyáltalán nem meglepő, hogy a public folderek tárolását is úgy célszerű elképzelni, hogy van külön a folder hierarchia és van külön a tartalom.

Amíg egy szerverünk van, nincs is különösebb baj. Ott vannak rajta a postafiók adatbázisok (melyiken mennyi) és emellett ott van az egy darab MAPI oldalról elérhető public folder adatbázis. (Több, ha megfeszülünk sem lehet.) A hierarchia és a tartalom egy szerveren figyel, az élet szép – és legfőképpen egyszerű. Nagyobb cégeknél viszont teljesen normális, hogy több Exchange szerverük van, esetenként egymástól meglehetősen távoli telephelyeken is. A felhasználói postafiókokkal nincs probléma, azok nyilván azokon a szervereken lesznek, amelyeket a konkrét felhasználók gyors hálózaton keresztül érnek el. De mi legyen a public folderekkel? Valamennyit itt is lehet szeparálni, amennyiben léteznek telephely specifikus folderek… de ez általában csak kis hányad. Marad az, hogy a public foldereket le kell tükrözni mind a központi, mind a telephelyi Exchange szerverekre. (Ez mellékhatásként egyben a rendelkezésre állást is növeli. Egyet fizet, kettőt kap.)

Vizsgáljuk meg, mit is jelent ez a kifejezés, hogy ‘letükrözni’? Le kell tükröznünk a hierarchiát? Nekünk ugyan nem. Az ugyanis olyan, mint az Alien nyála: áteszi magát még a saválló acélmenyezeten is. Amennyiben a folderek jogosultságát nem piszkáljuk, a folderszerkezetet – hierarchiát – minden telephelyen egyformán látni fogják. A tartalom… az már egy másik történet. Itt már mi szabályozhatjuk, hogy mi történjen. Ha akarjuk, letükrözzük. Ekkor ha valaki el akar olvasni egy nyilvános mappában lévő levelet, azt a helyi Exchange szerverről fogja megkapni. Alapértelmezetten biztos lehet benne, hogy ez a levél 15 percen belül friss. Persze nem kötelező tükröznünk. Biztos vannak olyan mappák, melyeket szökőévente használnak egyes telephelyeken. Ilyenkor rábízzuk magunkat az Exchange belső mechanizmusaira: ha nem találja meg a tartalmat azon a szerveren, amelyiken a felhasználó postafiókja van, ki fogja nyomozni, hogy melyik másik szerveren van belőle példány és onnan adja ki. Végül előfordulhat olyan eset, hogy a telephelyen csak szökőévente használnának egy foldert és akkor is tilos nekik: ilyenkor a két Exchange szerver közötti konnektoron egyszerűen le kell tiltani a public folder tartalmak elérhetőségének a közlekedését.

2. ábra Public folder referral tiltása

Közeledünk a cikk fő témájához. Akik üzemeltetnek többszerveres Exchange organizációt, tudják, hogy a tükrözés, vagy nevezzük mostantól népszerűbb nevén – a replikáció – egyáltalán nem olyan kezes bárány, mint ahogy a tankönyvek írják. Sőt. Megismerve a működési mechanizmusát, egyből Pratchett Korongvilágának sárkányai jutottak eszembe: azok a lények annyira bonyolult működésűek voltak, hogy csoda, hogy egyáltalán éltek.

II. A replikáció közelebbről

Meglehetősen száraz anyag fog következni: bemutatom a replikációban résztvevő szereplőket és a köztük lévő viszonyokat.

Magát a public folder replikációt az Information Store szolgáltatás menedzseli, azon belül is a Public Folder Replication Agent, becenevén PFRA. (Természetesen a replikációs üzenetek szállítását nem ő végzi – azért a mindenkori szállítási mechanizmus felel. Minden másért a PFRÁ-t kell ütni.)

A különböző szervereken található azonos foldereket replikáknak nevezzük.

3. ábra Egy konkrét nyilvános mappa replika listája

Az AD replikáció és a PF replikáció között időnként találhatunk hasonlóságot: az egyik ilyen az, hogy az időbélyeg egyik esetben sem domináns. Az AD replikáció esetében az ún USN érték hordozza a fontos információt, PF replikáció esetén pedig a Change Number, röviden CN.
Ez a következőképpen épül fel: <is -GUID>-counter. Gondolom, nem kell magyaráznom, mindegyik szerver Information Store szolgáltatása objektumként szerepel a címtárban és mint ilyen, van neki egy GUID értéke. A számláló pedig egy szerverhez kötődő, monoton növekvő érték. Amikor bármit változtatnak valamelyik lokálisan tárolt nyilvános mappabéli elemen, akkor a számláló értéke eggyel nő. Az így keletkező CN kötődik hozzá a megváltoztatott objektumhoz és lesz egyben a változás azonosítója is. (Amikor létrejön az objektum, az is egy változás – azaz már születése pillanatában mindenki kap egy CN értéket.)

Ez azért önmagában kevés. Létezik egy olyan fogalom, hogy Message State Information. Minden változáshoz rendelhető egy ilyen csomag. Három fő eleme van:

  • CN: change number
  • Predecessor change list: Ez egy lista. Azokat a CN értékeket tartalmazza, melyek már korábban kötődtek az illető objektumhoz. Figyelem, itt azok a CN értékek is megtalálhatók, melyek más szervereken keletkeztek!
  • Időbélyeg

A Message State Information elemek szerverek között utaznak.

Mindemellett a replikáció adminisztrálásához szükség van lokális információtárolásra is, erre valók az ún. Replication State táblázatok. Durván úgy kell elképzelni, mintha a Message State információkból egy olyan Excel táblát építenénk fel minden szerveren, amelyikben replikánként külön sora van az objektumoknak.

A CN értékeket általában össze szokták kapni egy csokorba. Ezt a csokrot CNset-nek nevezzük. Egy konkrét folder összes objektumának CNset csokrát pedig státusz információnak.

Fontos tisztáznunk, hogy mit tartunk a replikáció elemi egységének. Ez az egység az objektum – azaz ha egy objektum bármelyik tulajdonságának az értéke megváltozik, akkor a teljes objektum utazik. Egész konkrétan:

  • Hierarchia esetén pl. létrehozunk egy új könyvtárat vagy megváltoztatjuk egy könyvtár egyik tulajdonságát, – mondjuk a nevét -, akkor a könyvtárobjektum tokkal-vonóval, összes tulajdonságával együtt fog résztvenni a replikációs folyamatban.
  • Tartalom esetén új üzenet létrehozása, meglévő üzenet tulajdonságának megváltoztatása egyaránt azt fogja okozni, hogy az üzenet – az összes tulajdonságával együtt – részt fog venni a replikációban. (Értelemszerűen az összes tulajdonságba az elem tartalma is beleértendő.)

Látható, hogy a replikációs mechanizmus igazából sok kisméretű objektum replikációja esetén érzi jól magát. Ha nagyméretű csatolások vannak a levelekben, és valaki bármilyen apróságot is megváltoztat egy levél objektumon, az egész üzenet fog utazni, böszme csatolásával együtt.

A replikációs csomagokat a következőképpen kell elképzelni. A PFRA elkészíti a Message State információs táblát, ehhez hozzácsapja a megváltozott objektumot, a folder státusz információit, az egészet elkódolja, majd rávési a címzett nevét és továbbpasszolja a szállító mechanizmusnak. A kódolás base64 algoritmussal történik és úgy hívják, hogy TNEF (Transport Neutral Encapsulated Format). Az eredmény az oly hőn szeretett winmail.dat csatolás a levélben.

A felsorolás végére hagytam a legfontosabb táblázatot. Akármilyen replikációs lépés is történik, arról bejegyzés kerül az eseménynapló applikációs logjába – feltéve, hogy érzékenyre van állítva a logolás. Az események ‘type’ paramétere utal arra, hogy mi is volt a replikációs lépés.

Type Magyarázat
0x2: hierarchia A hierarchia egyik elemének replikációja történt meg.
0x4: tartalom A tartalom egyik elemének replikációja történt meg.
0x8: backfill igénylés Hiányzó elem (hierarchia/tartalom) pótlásának igénye.
0x80000002 (hierarchia) v. 0x80000004 (tartalom): backfill válasz Hiányzó elemek elküldése.
0x10: státusz Egy folder teljes CNset-jének elküldése egy replika felé (hierarchia/tartalom)
0x20: státusz igénylés Egy replikabeli folder teljes CNset-jének megigénylése.

Ez egy nagyon fontos táblázat. Aki tényleg érteni szeretné a későbbieket, addig ne is olvasson tovább, amíg egy firkálólapra fejből nem tudja reprodukálni ezt a táblát.
Amikor nyomozni kell, hogy mi is történt, ezekkel a számokkal fogunk dolgozni.

Most pedig menjünk végig egy egyszerű replikációs folyamaton, lépésről lépésre.

1. Béla módosít egy elemet a nyilvános mappában. (Ez a változás azon a szerveren fog megtörténni, amelyiken Bélának a személyes postafiókja is van. Amennyiben azon nincs meg a public folder elem, akkor az a szerver fog játszani, amelyikről Béla beolvasta az elemet.)

2. Az illetékes szerveren futó PFRA észleli a változást.

3. A következő replikációs ciklusban (alapértelmezésben 15 perc, egyébként pedig a konkrét public folder store tulajdonságlapján állítható) a PFRA megvizsgálja, hogy létezik-e a megváltoztatott elemnek replikája.

4. A PFRA kioszt egy CN-t és hozzárendeli az objektumhoz.

5. A PFRA elkészíti a replikációs csomagocskát. Ez objektumonként tartalmazza a Message State információs táblát és magát az objektumot. Emellé odacsomagolja még a feladó folder státusz információját is.
A levélforgalom csökkentése miatt egy csomagba nem csak egy változás adatai kerülhetnek bele. Hierarchia változások nagyon jól elvannak egymás mellett, hasonlóan az egy folderhez tartozó tartalomváltozások is. Hierarchia változás nem keveredhet egy csomagon belül tartalomváltozással. Hasonlóan különböző folderekhez tartozó tartalomváltozások sem keverhetők. (Ekkor egy csomagon belül két státusz információ menne.)

6. A PFRA ráírja a csomagra a címzett nevét és feladja. Akárhány replika is létezik, ő csak egy példányban adja fel a csomagot – a többiről már az Exchange szállítási mechanizmusa gondoskodik. A PFRA olyan szinten megbízik ebben a mechanizmusban, hogy minden visszajelzési igény nélkül be is vési a maga kis táblázatába, hogy az illető replikák szinkronban vannak.
Az applikációs logba bekerül egy 0x2 vagy 0x4 típusú bejegyzés, amennyiben érzékenyre van állítva a logolás.

4. ábra Replikációs csomag elküldésére utaló 0x2 bejegyzés az applikációs logban

7. A fogadó szerver PFRA szolgáltatása kicsomagolja a csomagot. Az applikációs logba bekerül egy 0x2 vagy 0x4 típusú bejegyzés.

8. A PFRA elemzi a Message State információs táblák értékét és ez alapján eldönti, mely elemeket kell módosítania a saját lokális adatbázisában.

9. A PFRA elvégzi a módosításokat.

10. A PFRA adminisztrál: átvezeti a módosításokat a saját Replication State táblázatában. A státusz információkban lévő CNset alapján leellenőrzi, hogy a folderre vonatkozóan minden objektumból tényleg a legfrisebb verzióval rendelkezik-e? Amennyiben nem, akkor pánikba esik és a backfill folyamatért szalajt. (Lásd később.)

Ezzel megvolt az alapozás. Holnap folytatom.

Korrekciók

  1. A korábban emlegetett IIFP… szép eszköz, jó eszköz, de az ingyenességén esett egy kis folt. Egyedül Windows2003 Server Enterprise verzióra hajlandó települni – tehát akinél éppen nem dohog egy ilyen a gépházban, annak bizony zsebbe kell nyúlni.
  2. A szintén korábban említett kukoricaprósza… hogy én mennyire balek vagyok. Most, utólag tudtam meg, hogy azt, amit én elkanalazgattam, még ki kellett volna sütni olajban. Akkor lett volna belőle kukoricaprósza… azaz lepény.

Remek parti volt

Előzmények:
Május végén voltam egyfajta természetgyógyásznál, akitől kaptam egyfajta speciális kezelést. Állítása szerint ezáltal az elkövetkező negyven napban ellenállóbb lettem az éjszakai fájásokkal szemben – viszont ebbe a negyven napba be kell iktatnom egy tíznapos méregtelenítő kúrát. Ennek az a lényege, hogy csak speciális ételeket ehetek (hajdinakása, köleskása, kukoricakása, barnarizs nyák), méghozzá egy nap csak egyfajtát. Inni ásványvizet vagy koffeinmentes teát lehet, azokból viszont sokat. Mivel június végén Horvátországba megyünk, így ahogy visszaértünk a bécsi kirándulásról, már dobtam is fel a platnira a hajdinát.

Egyvalamit felejtettem ki a számításaimból: azt, hogy Barnának elmaradt május végén az egri születésnapi partija. Márpedig ez minden évben nagy, összevont buli szokott lenni. Szüleim csörögtek ránk, hogy ugye megyünk? Mit lehet erre mondani? Barnának névnap/születésnap, az apjának születésnap, a kölykök meg egyébként is rég látták egymást… persze, hogy megyünk.

Anyám természetesen kitett magáért. Szombat kora délelőtt hurkával, sült kolbásszal és fasírtgombócokkal várt minket. Az egész előteret belengte a csemege uborka aromával keveredett sült kolbász illat. Ebédre húsleves volt, kijevi módra töltött rántott hússal, opcionálisan fokhagymásan lesütött hússal. Ebéd közben bontottak egy üveg bort, utána pedig jöttek a torták: egy diabetikus torta öcsém fiának és egy nagyobb joghurttorta a többieknek. Vacsorára anyám sütött egy nagy adag túrós süteményt, olyan tiroli rétes féleséget. Estefelé még beállított sógórnőm testvére, hoztak egy tepsi lúdlábszerű sütit. Mindezen kaják kint maradtak az étkezőasztalon, csipegetésre csábítva az arrajárókat.
Mindemellett apám előrelátóan már reggel behűtötte a sört, az esti meccshez.
Csak megjegyzem, a fentebb elsoroltak egytől-egyig a kedvenceim. Szemben azzal a kukoricaprószával, melyet végül egész nap kanalazgattam, meglehetősen savanyú képpel.
Innentől, úgy érzem, bármilyen kísértésnek ellent tudok állni.

 

 

Extreme vásárlás

A gyereknek mp3 lejátszó kellett a névnapjára. Igaz, volt neki discman-je, de az nagy és már egyébként sem sikk. Az ajándék pénzével ő rendelkezik, tehát ha ez kell neki, akkor legyen. Végülis találtam neki egy jófajtát, Creative Labs Zen Nova 512 lett kinézve az Extreme Digital katalógusában.
Itt követtem el az első hibát. Pedig sejthettem volna, hogy gáz lesz, mivel ebből az üzletből én még sosem jöttem ki elégedetten, még akkor sem, amikor sikerült megvennem, amit akartam.

Intermezzo: Legutóbb például ugyanennek a csemetének digitális fényképezőgép kellett. Végigálltam egy hosszú sort a Mamutban, majd végigálltam egy másik hosszú sort a pénztárnál, ahol közölték, hogy bankkártyával nem lehet fizetni. Mehettem automatát keresni valahol, majd utána állhattam újra be a hosszú sorba. Arról nem is beszélve, hogy a hitelkártyám éppen fel volt töltve, de a bankkártyámat ez a kivétel mínuszba vitte.
Reklamáltam.
– Hogy képzelik, hogy nem lehet bankkártyával fizetni? – kérdeztem a pénztárost.
– Nem én találtam ki, ne velem veszekedjen.
Itt ki kellett oktatnom a hölgyet, hogy kettőnk kapcsolatában ő képviseli a cégét és igenis, ha valami bajom van velük, akkor rajta vezetem le a mérgemet. Tessék szolgálati úton továbbítani.
– A weblapunkon lehet észrevételt tenni, írja meg oda – bökte ki.
– Meg is írom. De nem ott – nyugtattam meg.

No, elmentem megint a Mamutba. Az előttem lévő hölgy hosszú időre vette ígénybe az eladó türelmét. Az enyémet nem, mert nekem már az első pár perc után elfogyott.
Végül sorra kerültem.
– Mp3 lejátszó, Creative Labs, Zen, Nova, 512, sötétkék – soroltam. Gondoltam, hogy kiállítják a számlát és már mehetek is.
– Nincs. Csak zöld van – közölte némi billentyűkattogtatás után az eladó.
– Sötét?
– Világos.
– Köszönöm, az nem kell.
– A Visegrádi utcában van.
– Meddig vannak nyitva?
– Hatig.
– Mennyi most az idő?
– Öt negyven.
– Akkor ennek már lőttek.
– Dehogyis. A villamos negyedóra alatt ott van.
– Ne bolondozzon már. Esélytelen.
Ezzel eljöttem. Holnap úgyis lesz dolgom a Nyugati körül, majd beugrok érte.

A következő napon már óvatosabb voltam: indulás előtt felhívtam a központi számukat.
– Mp3 lejátszó, Creative Labs, Zen, Nova, 512, sötétkék – közöltem a telefonkagylóval.
– Igen van.
– Melyik üzletükben?
– Mindegyikban.
– Na ne. Tegnap zárás előtt voltam a Mamutban, azt mondták, hogy nincs.
– Azóta kaptak árut.
– Aha. Köszönöm.

Ettől függetlenül a Visegrádi utcába mentem.
– Mp3 lejátszó, Creative Labs, Zen, Nova, 512, sötétkék – mondtam, miután az előttem álló hapi alaposan megtárgyalta a fényképezés rejtelmeit az előadóval.
Kattogtatás.
– Nincs – nézett fel a hapi.
– Ne csinálja már. Egy órája kérdeztem meg a központot, akkor még volt.
– Igen, de azóta elfogyott.
Dühösen elindultam kifelé, aztán az ajtóból visszafordultam.
– Meg tudná mondani, mely üzleteikben van még?
– Persze. Az Erzsébet körútiban és a Mamutban. Ne rakassak félre egyet?
– Ne.

Ez utóbbi válasz kis magyarázatra szorul. Ekkor ugyanis már kezdtem ideges lenni. Egyáltalán nem voltam biztos benne, hogy a továbbiakban náluk akarok vásárolni, de ha esetleg igen, akkor sem tudtam, melyik üzletükbe menjek.
Így kisétáltam a villamos megállóig és a villamosra bíztam a döntést. A Duna felől jött az első.
A villamoson azért elmélkedtem a balszerencséről: mennyi esélye van, hogy pont abban az egy üzletben fogy el egy órán belül a cucc, amelyiket kiválasztottam? A többiben ugyanis még volt, legalábbis az előadó szerint.

Bementem az újabb üzletbe. Előttem kis család fényképezőgépet vásárolt, apuka részletesen faggatta az eladót (nem tudom, nem igaz, hogy értékesebb gépnél nem lehet előtte az Interneten tájékozódni…), anyuka idegesen feszengett, a két apró gyerek pedig ordítva próbálta lebontani a boltot. Külön emelte a hangulatot egy idősebb hapi, aki sokáig úgy nézett ki, hogy elém akar furakodni, de később kiderült, hogy csak a pultot akarta tanulmányozni.
Végül sorrakerültem.
– Mp3 lejátszó, Creative Labs, Zen, Nova, 512, sötétkék – közöltem blazírtan.
Ismerős kattogtatás.
– Sajnos nincs.
– Na ne csinálja. Húsz perccel ezelőtt voltam egy másik üzletükben. Ott mondták, hogy Önöknél még van!
– Igen. De azóta elfogyott.
Innen már úgy jöttem ki, hogy bebasztam az ajtót. Ezt így utólag már bánom.

Metró, ismét a Mamut. A tegnapi eladó fogadott.
– Mp3 lejátszó, Creative Labs, Zen, Nova, 512 – morogtam.
Felnézett.
– Sötétkék – tettem hozzá.
Szemmel láthatóan megismert.
– Azt az információt kaptam, hogy nemrég kaptak árut – fűztem hozzá, hogy ne nézzen teljesen hülyének.
Kattogtatás.
– Tényleg – derült fel az arca – Lesz még valami más?

Ennyi volt. Még végigélvezhettem a készpénzes vásárlás örömeit, de végre a kezemben volt a cucc. Itt már nem kötöttem bele a pénztáros csajsziba, pedig kedvem lett volna felhívni a figyelmét, hogy már a vevőit korbáccsal kezelő Metró üzletlánc is régen bevezette a kártyás fizetés lehetőségét… lassan ideje lenni már nekik is lejönniük a fáról.
Ember, nagyértékű árukat forgalmazó műszaki üzletlánc kártyafizetés nélkül… több, mint nonszensz.

Este átadtuk az ajándékot. Végülis megérdemelte a srác, egész évben jó teljesítményt nyújtott.
A legszebb persze az, hogy fogalma sincs róla, mi munka volt megszerezni ezt a cuccot.

Hétköznapi pszichológia 2

Alaphelyzet:

  • Valaki (kolléga, társasházi lakó) rendszeresen nem köszön vissza.
  • Te egy kedves, jóindulatú ember vagy.

Milyen stratégiát alakítasz ki?

  • Berágsz, te sem köszönsz. Ekkor a farok sikeresen rombolt: ha kicsit is, de olyanra formált, mint ő.
  • Továbbra is köszönsz neki. Ebből előbb-utóbb kialakul egy olyan állapot, hogy külön figyelni fogsz rá. Hiszen ha csak egyszer is hibázol, onnantól jogosan mondhatná, hogy ő azért nem köszön, mert te sem. (Legalábbis ezt fogod érezni.)
    Ez gyakorlatilag azt jelenti, hogy sokkal több figyelmet fogsz rászentelni, rá, a sötét bunkóra, mint a rendesebb népekre.

Nos…?

Rafal a Lurdyban

Egész jó volt ma az előadás a Lurdyban. Rafal hozta magát, annak ellenére, hogy most nem adott elő olyan bonyolult sztepptánc produkciókat, mint tavaly.

A sok érdekességből két dolgot emelnék ki.
Az egyik egy szakmai momentum. Rafal – csak úgy mellékesen – megemlített egy terméket, amelytől égnek állt a hajam. Elég sokat igyekszem olvasni Microsoft technológiákról, a területembe is vág… hogy a francba nem hallottam akkor még egy szót sem az IIFP-ről? Tisztességes nevén Identity Integration Feature Pack-nek anyakönyvezték és a Microsoft Identity Integration Server kisöcsikéje. (Remekül láthatóak a családi viszonyok, ugyanis a MIIS eredeti neve Identity Integration Server volt… csak aztán jött az átnevező kommandó.)
Amiért elsápadtam: az utóbbi években többször is beleszaladtunk tartomány konszolidációk, Exchange5.5 migrációk során abba a problémába, hogy igenám, de mi lesz a címtárakkal, ha külön erdőkbe kell tenni az addig békésen egymás mellett élő organizációkat? Igen, tudtuk, hogy van MIIS, de az ügyfelek sokallták az árát – így mindig nekünk kellett addig gyötörnünk az agyunkat, amíg össze nem állt egy megfelelően cifra tartományi rendszer.
Erre most itt van egy termék, mely simán szinkronizál Exchange címlistákat erdők között.
De továbbmegyek. Egyik ügyfelünknél egyre inkább körvonalazódik – hálaistennek -, hogy bizonyos fejlesztési célokra mégsem az AD sémát fogják módosítani, hanem csinálnak maguknak ADAM homokozót. Habár a fejlesztők még csak most ismerkednek vele, de már látom előre, hogy hamarosan fel fog merülni a kérdés: hogyan lehet ezt szinkronizálni az AD-vel? IIFP. Ingyér.

A másik megemlíteni való már nem szakmai jellegű. Morogni fogok.
Ott kezdődik, hogy nem ihatok kávét. Kellemetlen, de ki lehet bírni. Végülis az erős tea ugyanolyan élénkítő hatású, talán még egy kicsit tovább is tart a hatása. Feltéve, hogy van. Egyszerűen el sem tudom képzelni, hogy miért nem tudnak kitenni egy doboz filtert az asztalra a forróvizes tartály mellé. Maximum ötszáz forint – semmi a többi tételhez képest. Így viszont gyakorlatilag végig küzdhettem az álmossággal.
Aztán nem is bírtam végig. Tudom, egyéni szocprobléma, de éppen olyan szigorú méregtelenítő kúrán vagyok, hogy csak gabonakásákat ehetek és teát ihatok. Gondoltam, semmi probléma, majd a szünetekben iszok egy-egy teát, így nem fog kilyukadni a gyomrom az éhségtől és még a szellemem is friss marad. Na ja. Ebédszünetig bírtam. Aztán jó előadás ide, jó előadó oda, a túlélés mellett döntöttem és hazamentem barnarizsnyákot enni vörös teával.
Legközelebb meg majd viszek filtert és merülőforralót.

Nem vagyunk czukorból

Hát… több okból sem lesz könnyű dolgom.
Egyfelől, annyira lehajtottuk magunkat minden nap, hogy este még kártyázni sem volt erőnk, nemhogy félrevonuljak és feljegyezzek apróságokat az illető napról. Így most csak annyi lesz, amennyi így estefelé eszembejut a három napból.
Másrészt nagyon nehéz úgy írni Bécsről, hogy az ember ne kezdjen párhuzamot vonni. Régebben mondták, hogy Bécs és Budapest között nagy a hasonlóság. Nos, ha valaki most mondana ilyet, rögtön ápolóért küldetnék. Az ódon épületek, az öreg város, a folyó… ezektől akár még lehetne is, de az emberek mentalitása, a város hangulata, az érzés, hogy a város a benne lakókért van… mely érzésnek nyoma sincs Budapesten, sőt, itt mintha a város pont azért lenne, hogy minél hamarabb kinyírja kellemetlen lakóit – nos, ez nagyon más. Attól tartok, az állandó összehasonlítgatást és az ebből eredő frusztráltság gerjesztését nehéz lesz elkerülni. Őszintén szólva nem is vagyok biztos benne, hogy teljesen el akarom.

2006.06.03 Szombat, Sopron

Már rögtön az indulás sem volt egyszerű. Eredeti terv szerint pénteken mentünk volna Sopronba, de az özönvíz miatt átszerveztük a kirándulást. Kilőttük a soproni bobozást, kilőttük a csavargást a Lővérekben és bevállaltuk a város megtekintését a valószínűsíthető hidrofílikus közegben. Sokat dobott a helyzeten a nemrég vásárolt rexasztal és a családtagokban fellángolt golyóböködési vágy. Soproni kollégától jó tippeket kaptam (köszönjük Pisti), így címekkel felszerelkezve vágtunk neki egy kényelmes reggeli összekészülődés után.
Mivel tervben volt Bécsben a Schönbrunn kastély, mindenképpen szerettem volna előtte megmutatni a kölyköknek az Esterházy kastélyt Fertődön, ne érezzék egyből a negatív kontrasztot. Természetesen ott is szakadt az eső. A kastély azért még belefért, de a kőfejtőt elhalasztottuk. Szerencsére.

A szállást a Wieden panzióban már hónapokkal korábban lefoglaltuk. Semmit nem tudtam róluk, egyszerűen csak megtetszettek az Interneten. Ehhez képest nekünk bejött. Az előző mondat kulcsszava a ‘nekünk’. Ugyanis nem volt minden tökéletes, de ami nekünk kellett, az jó volt. Az apartman gyakorlatilag egy nagy, kétszobás lakás. A konyha béna volt, evőeszköz nem igazán tobzódott a fiókokban… de nem is hiányoltuk. A fürdőszobában a zuhanyfülke ajtaja kétféleképpen működött: vagy be tudtuk húzni vagy szétesett az egész fülke. A nagyobbik szobában a kanapé az idióta fajta IKEA stílust képviselte, melynek két legfontosabb stílusjegye, hogy meghökkentően néz ki és képtelenség benne kényelmesen ülni. De minden más jó volt. A hatalmas térben kényelmesen elfértünk, az ágyak jók voltak – és ez a lényeg, mert gyakorlatilag csak aludni jártunk be. Nagyon közel volt a belvároshoz, a Tűztorony kb négy és fél percbe telt gyalog. Alaphelyzetben nem rajongok a szállásdíjba applikált reggeliért, de most le a kalappal. Olyan bőséges reggeli volt, hogy még Barnán is kifogott. Volt svédasztal és a srác egyszerűen nem hitte el, hogy annyit ehet, amennyi belefér: ha valami elfogyott, szinte azonnal pótolták. Emellett lehetett kérni komplett reggelit is (virsli, ham&eggs, felvágott tál) és amíg kihozták, addig ott volt a svédasztal. Meg utána is. (Barna meg is kapta a Deficit becenevet.) Gyakorlatilag úgy jól lehetett lakni, hogy jó sokáig nem is gondoltunk utána ebédre; ez különösen a bécsi napon jött jól, amikor semmi nem úgy sikerült, ahogy elterveztük – de erről később.

No, vissza a történethez. Indulás előtt megnéztük Pártai Luciát. Igaz, a múltkor csúnyán hibázott, de hátha most. Azt mondta, hogy a viharfelhők áthúzódtak keletre, nyugaton száraz, de felhős idő lesz. Talán Győrben eshet egy kicsit.
Ez utóbbit jól eltalálta, Győr mellett akkora felhőszakadást fogtunk ki, hogy a legerősebb fokozatban sem bírta az ablaktörlő. Amit már kevésbé talált el, az az volt, hogy Sopront is megszállta egy gusztustalan esőfelhő. Kora délután érkeztünk meg, persze szakadó esőben. A GPS megint hülye volt, simán bevitt egy szálloda magánútjára. Becsületére legyen mondva, utána viszont segített kikeveredni onnan. Leccuccoltunk és megkerestük a kolléga által ajánlott Jégverem éttermet. Az esőben bejártuk jól a környéket, mire megtaláltuk a helyet: pedig gyakorlatilag pont a szállásunkkal szemben volt. Ennyit a szerencsétlen irányválasztásról. Az étteremről csak jót tudok mondani. Előre szóltak, hogy óvatosan rendeljünk, az adagok igen emberesek. Pusztán kisadag kajákkal teljesen jóllaktunk. Időnként láttuk a nagy adagokat is – nem volt nehéz, kilógott rendesen az emberek mögül.
A háromfogásos ebéd után volt egy óra csendes pihenő, majd öt óra körül nekivágtunk a városnak. Szakadó esőben, persze. Csavarogtunk, tekeregtünk, ahogy kell. Láttunk szép helyeket, hangulatos utcákat. Mindössze annyit kellett tennünk, hogy nem arrafelé mentünk, amerre a sok ember. Végül megnéztük az ún. nagy látványosságokat – kellettek ezek is a város hangulatához, természetesen. Hét óra körül pedig átsétáltunk a Biliárd klubba. Nagyon jó döntés volt. Egyrészt az eső makacsul szakadt, a klub pedig fedett hely volt. Másrészt, írd és mondd, 300 pénz volt egy asztal egy órára. Kicsit tartottam tőle, hogy három abszolút kezdővel a törzsközönség gúnyolódásának esünk áldozatul, de persze ilyesmiről szó sem volt: egyrészt a kezdeti homályok után mindenki belejött, másrészt a kutya sem foglalkozott velünk. Végül pusztán a sajgó derekak kényszerítettek arra, hogy abbahagyjuk. Két és fél óra játékért, egy csomó üdítőért, kapucsínóért, sörért fizettünk 2200 forintot. Csak összehasonlításként, a durván 15 perc Tűztorony mászkálás volt 1500 pénz. És mindkettő bőven megérte.
Este nyilván mindenki összetörve mászott ágyba. Én ugyan mondtam, hogy ez mind lófarok a holnapi fáradtsághoz képest, de azt hitték, hogy ez csak egyike bizarr tréfálkozásaimnak.

2006.06.04; Bécs

Korai ébresztő volt, várt minket a császári város. Előtte megtapasztaltuk a bőséges reggeli élményét, aztán megnéztük újra Lucia drágát. Azt mondta, hogy csak keleten várható eső, nyugat csontszáraz lesz. Be is vágtak egy műholdképet, szépen látszott, hogy a Kisalföld felett semmi felhő, de gyk. Burgenland is tiszta volt. Hurrá.
Ehhez képest, ahogy kiértünk Sopronból, nekiállt cseperegni, Bécsnél meg már szakadt az eső.
Még indulás előtt végignéztem a bécsi parkolási lehetőségeket és végül a Stadtpark melletti Beethoven platz mellett döntöttem. Ez volt a legközelebb a Ring egyik végéhez és úgy terveztem, hogy bejárjuk a félkört, utána bevetjük magunkat a sűrűbe, majd a Mariahilfer utcán lenyomulunk a Schönbrunn kastélyhoz, megszálljuk az Állatkertet, végül a 4-es metróval visszasurranunk a városi parkhoz.
Mondanom sem kell, a tervhez képest némileg felpuhult a megvalósítás.
A körút még viszonylag sima volt. Hol csepergett, hol szakadt az eső, de úgy csináltunk, mint a bécsi konflislovak: szartunk rá. Az mindenesetre elmondható, hogy a szökőkutak nem örvendtek a máskor szokásos júniusi népszerűségüknek.
Beszéljünk most a döbbenetes dolgokról. Teljesen lemeredtem pl. a rengeteg kerékpárút láttán. Valahol itt kezdődnék… nem csak az fontos, hogy tényleg legyen kerékpárút, hanem ott, hogy ez a szemlélet annyira beépüljön a gondolkodásba, mint ahogy ennél a közlekedési lámpánál is látszik.
De volt más meglepetés is. Láttuk a becsületkasszás újságvásárlást. Mindenen, mely oszlophoz hasonlított, ott lógott egy-egy zacskó, bennük különböző újságok. Ha kellett, bedobtad a pénzt a kasszába és kivettél egy újságot.
Hasonlóan nagy élmény volt a bérbringa. (Itt, az Opera mellett látható is néhány.) Csak gondoljuk végig: kiveszel egy cangát, mész vele X ideig, majd visszaviszed. A visszarakáskor számolódik ki, hogy mennyit kell fizetned érte. Azaz ha nem viszed vissza, nem kell fizetned, plusz van egy kerékpárod. Nálunk vajon meddig működne ez a koncepció?

Mindemellett nem kell magunkat mindenféle erkölcstelen, jellemtelen alakoknak elképzelnünk, pusztán mert mások még a reflexeink. Nagyon sokat számít a jólét és annál is többet a hosszas jólét. Magamról tudom, hogy amióta megnyugtató anyagi körülmények között élek, mennyire megváltozott a világképem és az erkölcsi hozzáállásom. Nem lehet bebolondítani az ‘ingyen’ varázsszóval és döntéseimnél egyre kevésbé befolyásolnak anyagi szempontok. (Oké, nyilván hétköznapi határok között.)
Ugyanez érvényes lehet egy városra is. Akinek aprópénz az egy euró egy napilapért, az nem olcsójánoskodik a zacskóba rakott újságért. Az az ember már eljut addig a gondolatig, hogy az újság elkészítése pénzbe kerül, tehát ha holnap is olvasni akarja a kedvenc lapját, akkor be kell dobnia az érmét. Nálunk ez még úgy van, hogy kivesszük az újságot ingyen, most, mert az már biztos… aztán a többi meg le van szarva.
Szeretnék hinni benne, hogy 40-50 év elég lesz ahhoz, hogy ez az ország is eljusson odáig, hogy ne egyik napról a másikra éljen, hanem megengedhesse magának az erkölcs luxusát. Feltéve, persze, hogy lesz akkor még emberi civilizáció.

Ami szintén szembeötlő volt, az az, hogy Bécsben van hely. A Ring annyira széles, hogy pl. vasárnap délelőtt tele volt futó emberekkel. Bőven volt helyük, a fák alatt. Elfértek a kerékpárút és a járda között. El tudná valaki ugyanezt képzelni Pesten a körúton? Mindezt úgy, hogy a Ringgel párhuzamosan megy egy másik széles út, mely elviszi a forgalom nagy részét.
Pesten ugyanezt a tágasságot nem lehet már elérni… de az sem megoldás, hogy a zsúfolt utcákba beengedjük azt a rengeteg autót. Bécsben a Ringen belül az utcák jó része zárt terület. A Ringen megy egy sűrű villamosjárat, alatta végig megy egy metró. Metróból egyébként is van egy csomó, de ahogy néztem, ezek nem olyan mélyfúrásúak, mint nálunk. Simán elmennek a kéregben, sőt a vizek felett is láttunk érdekes megoldásokat.
A magam részéről nagyon várom már a körgyűrű bezárását, elterelő utak építését – és azt, hogy lezárható legyen végre a körúton belüli része a városnak. Hogy ne kelljen fuldokolni sem az Üllői sem a Rákóczi úton… magáról a körútról nem is beszélve. Persze ehhez pénz kellene (EU?), meg lendületes városvezetés és egységes szándék. Ehelyett van ez a…

No, vissza az élménybeszámolóhoz. Délutánra néha már el is állt néha az eső. A belvárosi csalingázást kifejezetten élveztük. Az egész úgy szép, ahogy van. Tiszta, szellős – és a történelmi épületek nagyszerűek. Erről többet nem igazán tudok írni, tessék megnézni a fényképeket.
A komoly Bécs mellett essen szó az idióta Bécsről is. Nekem speciel tetszett, hogy az impozáns Rathaus előtti térre kiraktak vagy száz kosárpalánkot, aztán hagy szóljon. Még esőben is ott pattogtak a labdák meg a kölykök.
Aztán ezen a kirakaton is jót mosolyogtam. Vajon melyik másik városban képzelhető el, hogy a kirakati próbababák mellett ott flangál két kirakati próbaba tacskó (wiener dog) is? És jó volt még ez a tetoválószalonos merdzsó is. Meg az egész biztosan megállni tilos.

Végül az árakról. Bár korábban megfogadtam, hogy külföldön nem fogok foglalkozni az árakkal – ami kell, megvesszük és kész. Ez Bécsben nem annyira jött be: azért ez egy igen drága város. Az első pofon a fagyi volt: egy gombócot 1,7 euróért mértek, ami a jelen árakon durván 450 forint. Persze, azért ettünk, de a szürcsölés rendesen váltakozott a fogszívással. A másik durvulás a tömegközlekedésnél volt. Azt tudtam, hogy van öt eurós napijegy, mely mindenre jó. Ilyet nem akartunk venni, de ez alapján az egy zónára vonatkozó, egyszeri utazásra jó jegyet olyan 50-90 cent közé lőttem be. Ehhez képest kezdtem furcsán szedni a levegőt, amikor megláttam, hogy darabja 1,5 euró. Nyolc jegyet kellett bevetnünk a csavargás során, ez bizony 3200 forintba került.
Rövid magyarázat azoknak a jó megfigyelői képességekkel rendelkező embereknek, akik még emlékeznek a tervezésre. Igen, ott csak négy jegy volt betervezve, de a Westbahnhof-nál elfogyott a szufla. Különösen, amikor jeleztem, hogy ez durván a fele a kastély felé vezető útnak. Itt azért felugrottunk a villamosra.
A következő korrigálás az Állatkertnél volt. Ekkor már elmúlt öt óra és a pestiből kiindulva már nem vágtunk bele. Majd legközelebb.
Ja, a legnagyobb korrigálási sorozat. Külön étteremmel nem készültem. Akiket kérdeztem, azt mondták, hogy Bécsben nem lehet hibázni, mindegyik étterem jó. Azt terveztem, hogy olyan 1 óra körül bemegyünk a legelső étterembe. Mit ád az ég, pont a Schotten ringnél kaptuk el ezt az időt és nem találtunk a környéken egy szimpatikus éttermet sem. Ezzel szemben a belvárosban belefutottunk egy jellegzetes wurst árusba. Gyorsan megbeszéltük, hogy eszünk valami helyi finomságot és majd késő délután eszünk étteremben. Ezzel nem is lett volna baj, hat óra körül megvolt a késő délután és találtunk éttermet is… csakhogy ekkor már csak 59 euró volt a zsebemben. Először nem érzékeltem a bajt, ez ugye közel 16e forint, gondoltam négy darab bécsi szelet csak kijön belőle. Nos, nem. Úgy jött volna ki belőle, hogy nem kérünk sem savanyúságot, sem semmilyen innivalót. Bankom a külföldi pénzkivételt 1500 forinttal bünteti és valahogy ez így együtt kezdte átlépni nálam az ingerküszöböt. (Vegyek ki 10 eurót 2600-ért, meg fizessek 1500 sarcot…) Kártyával pedig nem szívesen fizetek étteremben. Nevezzetek paranoiásnak, de ez nem változtat a helyzeten. Végül gyors kupaktanács, majd úgy döntöttünk, visszahúzunk Sopronba. Az út nincs egy óra és majd vacsorázunk egy nagyot a Jégveremben.
Nem volt rossz döntés, mert a parkolóházban a parkolóautomata kifogott rajtam. Egyszerűen nem bírtam rájönni, hogyan lehet egyszerre beledugni a parkolókártyát és a bankkártyát. Végül kápéval fizettem, jólesően nyugtázva, hogy szerencsésen nem vertük el a zsét wienerschnitzelre.
Megint valami, ami szokatlanul jól működik odakint: táblázás. Életemben először jártam Bécsben autóval, a GPS pedig feldobta a talpát még Sopronban. Ennek ellenére simán, eltévedés nélkül landoltunk befelé a Stadtspark-nál, és kifelé is ugyanilyen olajozottan értünk ki az A3-ra. Az összes segédeszköz a táblázás és egy 21(!) éves gyűrött Bécs térkép volt, melyet Nej kezelt boszorkányos ügyességgel, kiérdemelve a ‘bongyor GPS’ címet.
Sitty-sutty Sopronban is voltunk, átsétáltunk az étterembe… amely valami rendezvény miatt tele volt. Ösztöneinkre bíztuk magunkat, besétáltunk a belvárosba. Én ugyan mondtam a Gyógygödört, de a család valami konszolidáltabbra gondolt. Aztán ahogy a csajok meglátták a Fogas éttermet, egyből döntöttek is. Patriarchátus… ugyan már.
De ez sem volt rossz döntés. Mindenféle finom halak kerültek terítékre és a férfiszakasz sem panaszkodhatott. Barna megszerezte végre reggel óta áhított bécsi szeletét, én pedig életem egyik legfinomabb tárkonyos vadragu levesén estem túl. A háromfogásos, nagyon finom vacsora tokkal-vonóval volt 9e pénz.
Furcsa ez… tulajdonképpen ez volt a második ostromom az echte bécsi gasztronómia felé… és megint az anyagiakon buktam meg. Az első esetben ez valahol érthető is… de most bennem volt a csakazértis szándék – aztán mégse sikerült.
Nyilván megint gyors zuhanyzás és alvás volt az esti program. A kutyák iszonyúan ugattak.

2006.06.05; hazafelé

Két biztos pont volt a napban. Az egyik, hogy este otthon szeretnénk aludni, a másik pedig, hogy ebédelni a Ráspi étteremben kellene. Nem túl bonyolult dolgok, de mégis majdhogynem lehetetlen feladatra kényszerítettek.
A panziót tízig kellett elhagyni és a tegnapi nap után nem akartunk korán felkelni. Csakhogy a kései reggeli után mivel húzzuk ki az időt ebédig? Az étterem jó 5 kilométerre volt, és az összes szóbajöhető program egy kőfejtő a faluban.
Jobb híján ez maradt. A kőfejtőt ismertem korábbról, jó harminc évvel ezelőtt jártam már itt. Nem sokat változott.
Végül is, simán elbohóckodtunk délig. Barna lemakrózott minden vadvirágot, de maga a táj is nagyon fotogén volt.
Persze problémát okozott, hogy ekkor a társaság még nem volt igazán éhes – de végül teljesen váratlanul ez is megoldódott.
Ja, hogy miért Ráspi. Többek között azért, mert eddig csak jókat hallottam róluk. Márpedig egy olyan étterem, mely elismerten ott van a top10-ben, de még nincsenek annyira elszállva az áraik, megér egy benézést, különösen akkor, ha az ember ebédidőben úgyis éppen arra jár. Nos, a találkozás az elit gasztronómiával nem volt meglepetések nélküli – különösen úgy, hogy az előző esti kaja emléke még nagyon élt bennünk. Először is, az árak azért már nem voltak alacsonynak nevezhetők. Ránézésre összefutott az ember szájában a nyál… szinte mindenből kértem volna egy harapást, hogy megkóstolhassam, mit is kérek majd… de így, beleválasztani az elég húzós árú ételekbe… végül maradtunk az alacsony árfekvésű ételeknél. Ezeket sem bántuk meg, nagyon finomak voltak… és nagyon kis adagok. Sopronban megszoktuk, hogy mindenhol bazi nagy adagokat vágtak hozzánk… itt, nem. Itt inkább a minőségre mentek rá. Szerencsére. Ugyanis éppen nem voltunk nagyon éhesek. Viszont ilyen szalvétagombócot még nem ettem soha és a marhapörkölt is megérne egy ódát. Apró érdekesség, hogy üdítőital nincs, helyette házi gyümölcslék vannak, melyek gyakorlatilag szörpök. A fogashoz viszont járt automatikusan egy deci rozé. Dóra ilyet nem iszik, én vezettem, így kénytelen volt Barna meginni. Az első néhány korty után bejelentette, hogy ez jobban ízlik neki, mint a sör… ezentúl ilyet fog inni.
Viszont egy nagy fekete rosszpont: a kapucsínóba tejhab helyett hideg tejszínhabot raktak, így az egész már a kihozás pillanatában langyos volt. Ilyen helyen ekkora csúnya hibát… nem kellett volna.

Erre a napra még egy programpont volt beütemezve: Nagycenk. Azt tudtuk, hogy a kastély be lesz zárva, de gondoltuk a gyerekvasutat megnézzük. Barna durván két hét múlva jön ide két nap vendégfellépésre, legalább lássa, mi vár rá. Nos, látta.
Pont akkor érkeztünk, amikor bemondták, hogy a vonat azonnal indul.
– Te, fussunk, hátha tudunk közeli fényképet csinálni róla! – szóltam oda a srácnak.
– Ugyan már. Amikor ezt mondják, akkor még percek vannak az indulásig – legyintett.
A jó öreg vasutas szellem.
Odaértünk. Váratlan ötlettől vezérelve odafordultam az egyik gyerekhez.
– Szia, lehet a vonaton is jegyet venni?
– Azt ugyan nem – válaszolta.
– Ejnye – vakartam meg a fejem.
– Józsi, ne indíts! – kiáltotta oda a társának.
Ezután Józsival elmentünk az épülethez. Komótosan kinyitotta a pénztárat és nekiállt letépkedni a nyolc jegyet.
– Te, nem fog elmenni közben a vonat? – idegeskedtem.
– Az ugyan nem. Én indítom – közölte hanyagul.
És tényleg nem ment el. Az a vonat, amelyhez én futni akartam, hogy egyáltalán fényképközelbe kerüljön, még bevárta, amíg kinyitják a pénztárat, megváltjuk a jegyet és felszállunk. Hja kérem, ez múzeumvonat.
Vonatoztunk jó tíz percet oda, ugyanannyit vissza, jó volt. Aztán Barna levette az inkognitóját, elvegyült a vasutasok között. Így tudtuk meg, hogy piszok mázlink volt, ugyanis felváltva szoktak indulni rövid és hosszú járatok. Mi pont egy rövidet fogtunk ki. A hosszú másfél óráig zötyögött volna a szántóföldeken.

Végül sétáltunk még egy kicsit a Széchenyi kastély parkjában is. Eleve nagyon furcsa volt, hiszen mindkét napon bejártunk egy-egy kastélyt, nem is akármilyeneket. Mégis ez a picike volt a legbarátságosabb. Ebben tudtam volna elképzelni, hogy eléldegélek. Minimális kertészművészet, a kastély mögött pedig szintén minimálisan gondozott park. Itt éreztem azt, hogy legszívesebben leheveredtem volna a nagy fa alá, nagy ívben hanyagolva az etikettet.

Nos, ennyi. Összességében mindenhol hagytunk el valamit (Sopron: Lővérek, Bécs: állatkert), szóval nem lepődnék meg olyan roppant nagyon, ha valamikor megismételnénk ezt az utat.

Linkek: