TagKiMivelSzív

Apu, hod med be

Jó téma, napokig lehetne cikkezni róla. Konkrétan arról van szó, hogyan nyúl bele a tűzfal a legegyszerűbb adatáramlásokba is. Melyekről persze kiderül, hogy nem is olyan egyszerűek.

Az első sztorink egy világméretű hálózaton történt. Két Exchange organizáció között kellett Free/Busy szinkront összelőni. A túloldal Amerikában volt, jó nagy időeltolódással. A kommunikáció enélkül is igen nehézkesen ment, ilyen környezetben nem egyszerű összehozni egy élő kapcsolatot, hogy mind a két oldalon ott üljön a megfelelő mérnök és szinkronban taperolják a billentyűzetet.

Előtte határozottan felhívtam a tűzfalas kollégák figyelmét, hogy a két host között any-any kapcsolatot kérek az oldalunkon. Belső hálózatról van szó, épp elég lesz az F/B szinkronnal játszanunk, első körben nem szeretnénk, ha a tűzfal bekavarna. (Utána lehet majd szigorítani.) Megigérték, beállították.

Eljött az idő. Próbálkoztunk. Nem működött. Kiderült, hogy a túloldali tűzfalon mindösszesen néhány portot engedélyeztek, csak éppen ezt a portlistát elfelejtették közölni. Mi viszont az Exchange megfelelő szolgáltatását nem korlátoztuk konkrét portokra. Némi gondot jelentett, hogy az általuk engedélyezett portokat nálunk már más Exchange szolgáltatások használták. Hasraütve kiválasztottunk néhányat a környékről (6xxx), a túloldalon engedélyezték a tűzfalon, nálunk ugye nem kellett.
Továbbra sem működött a szinkronizáció. Izzadtunk még egy sort, majd kölcsönös és sűrű sorry-k mellett befejeztük a közös munkát. Majd legközelebb.

Másnap a biztonság kedvéért rákérdeztem a helyi biztonsági erőknél, hogy tényleg any-any lett-e beállítva? Mellékeltem a konkrét portszámot is. Erre kaptam egy olyan választ, hogy jojózott a szemem. Ugyanis a véletlenszerű porttal pont beletaláltam egy általam még csak soha nem is hallott protokoll tartományába, melyet a konkrét tűzfalon nem engednek át direktben, hanem proxyznak. Innentől jókedvű anyázásba fordult a levelezés, én próbáltam elmagyarázni, hogy az any-any azt jelenti, hogy a két host között minden kommunikáció transzparens, ők viszont ragaszkodtak ahhoz, hogy az any-any az egy beállítás a szabályon, de nem érinti a különböző protokollproxykat.

A vége az lett, hogy kerestünk egy olyan portot, amelyiken biztosan nincs semmi trükközés, a következő partira az amik módosították a náluk lévő tűzfal szabályát, be is indult a kommunikáció.

A második sztori nem sokkal ezután esett meg egy kollégámmal és kisértetiesen hasonlított az előzőre.

Ügyfélnél két telephely, két AD site. Mindkettőn vannak Exchange Hub Transport szerverek. A jelenség: nem mennek át a levelek. Ott állnak a várakozási sorban, és azt mondják, hogy a túloldali szerver nem képes az Exchange szerver autentikációra. (Lásd a korábbi cikk.) A tűzfalas kolléga szerint a hostok között a kért portok engedélyezve vannak.
Ami alapvetően igaz is volt, de amikor megpróbáltak telnetelni, elég érdekes válaszokat kaptak. Lényeg a lényeg, a tűzfalas úriember csak azt felejtette el közölni, hogy a készüléken be van kapcsolva a MailGuard, amelyik meglehetősen szigorú ellenőrzést gyakorol az smtp forgalom felett: egyedül a HELO, MAIL, RCPT, DATA, RSET, NOOP és QUIT parancsokat támogatja, minden más tiltott. Igen, már az ESMTP és az AUTH is.
Nyilván a kikapcsolás után beindult minden.

Katasztrófa

Milyen már, amikor a katasztrófa-visszaállítási teszt során következik be a katasztrófa?

Elmesélem a sztorit. Tanulságos. Először ugyanis elböktük, aztán viszont kimásztunk belőle.

Mivel egy komplett datacentert kellett visszaállítanunk, mondanom sem kell, egy csomó ember nyüzsgött a munkán. Az én feladatom meglehetősen korlátozott volt, a levelezésnek kellett mennie a visszaállítás után, oszt jónapot.
Egy teljesen klasszikus CCR/SCR rendszerről van szó, többször is végigjátszottam már ilyen teszteket, bent volt egy dossziéban a szükséges egységcsomag. Nem mondhatnám, hogy túlzottan ideges voltam. A CCR/SCR replikációra ránéztem még a teszt előtt, normálisan ment.

Aztán egyik délután kilőtték a jelzőrakétát, elvágták a vezetéket a két telephely között. Másnap reggel megkérdeztem a PM-et, hogy tényleg elvágták-e a kábelt. Ja.
Oké, a disable-storagegroupcopy paranccsal kiirtottam az irmagját is a standby node-nak az éles rendszerből, majd vártam, mikor szólnak, hogy mehetek a DR telephelyre, stoppolni. (A kiirtás nagyon fontos: mint nemrég is írtam, ha fizikailag elérhetetlenné válik az SCR, akkor a backup nem törli a logokat, így viszont hamar feltelnek a logpartíciók.)

Eltelt pár nap, szóltak.

Kezdtem az első lépéssel, az adatbázisok macerálásával.

Itt most egy kis kitérő jön. Legyen már szakmai anyag is az írásban, ne csak egy szívás története.
Az SCR node az egy furcsa lény. Felkerülnek rá az Exchange dll-ek, lesz rajta konzol és shell… de Exchange szerver, az nem. Nem fogod látni sehol sem a konzolban. De még a shellben sem. A jelenlétéről is csak akkor fogsz tudni, ha néhány parancsnál használod a -standbymachine kapcsolót.
Ennek ellenére vannak rajta adatbázisok. (Még szép, hiszen ez az egész elv lényege.) Information Store, az nincs. Viszont van Microsoft Exchange Replication szolgáltatás.

Na most, mire is lehet használni egy ilyen szervert?

  • Database portability
    Valamilyen oknál fogva egy adatbázisodat egy másik szerveren szeretnéd felcsatolni. Lehet, hogy kidőlt az SCR forrásod alól a diszk alegység, lehet, hogy kidőlt a CCR-ed alól az az egy SAN, amelyiken mindkét adatbázispéldányok laktak (ugye-ugye), lehet, hogy át akarsz vinni egy adatbázist egy tesztkörnyezetbe. Nos, erre az SCR adatbázisok tökéletesek.
  • Site Resilience
    Az SCR forrásod elpárolgott. Semmivé lett. Te pedig szeretnél máshol, más telephelyen, az előzővel egyező néven létrehozni egy új szervert, majd ez alá felcsatolni az SCR adatbázisokat.

Akármelyik esetről is legyen szó – jelenleg ugye a második játszik – az első lépés az adatbázisok preparációja. Rájuk kell játszatni a logokat – és egyáltalán, olyan állapotba kell hozni, hogy az adatbázis felcsatolható legyen.
Erre szolgál a recover-storagegroupcopy parancs, méghozzá a következő szintaktikával:

recover-storagegroupcopy -identity server\sg -standbymachine scrname -force

Térjünk vissza a konkrét történethez. Kiadtam a fenti parancsot – és azt mondta az a gonosz EMS, hogy nincs ilyen nevű SCR szerverem. Nyilván begépeltem még néhányszor, hátha elütöttem egy karaktert, beírtam a teljes DNS nevével, adtam meg -domaincontroller értéket… hiába. Próbálkoztam a guglival is, de csak annyi választ kaptam, hogy ha ezt írja ki, akkor tényleg nincs a rendszerben ilyen nevű SCR.
Hát ez meg hogyan lehet?

Úgy, hogy – most nem részletezendő okok miatt – még rögtön a teszt elején pár percre összenyitották a két telephelyet. Mi történt? A címtár konfigurációs névtere egyből lereplikálódott a DR telephelyre. Benne az az információ, hogy én akkor már lebontottam az SCR kapcsolatot – azaz nincs SCR a rendszerben. Szépen vagyunk. A DR telephelyen nincs más, amiből építkezhetnénk, csak az SCR node. Ami jelenleg nincs.

Vegyük sorra a lehetőségeket.

  • Húzzunk fel egy kamu clustert az élessel megegyező névvel a DR telephelyen, majd építsünk ki egy SCR kapcsolatot? Az égegyadta világon semmi értelme sincs.
  • Tegyük vissza az SCR szervert az éles környezetbe és építsük ki újra az SCR replikációt? Ez megoldás lenne, de DR teszt során még csak gondolni sem szabad ilyesmire. Nincs éles környezet.
  • Egy korábbi system state mentésből töltsük vissza a konfigurációs névteret – azon belül is az Exchange ágat – autoritatív módon a DR telephelyen? Ez akár még működhetne is, csak éppen ekkor már az összes felesleges DC ki volt irtva a DR címtárból, a meglévők meg már annyira el voltak állítva, hogy esélytelen volt a visszatöltés.
  • Próbáljuk meg Eseutil-lal feljátszatni a logokat? Biztos, hogy a restore-storagegroupcopy csak ennyit csinál? Itt ugyanis az a gond, hogy ha mégsem, akkor nagyot bukunk, mivel a különbség nem itt derül ki, hanem egy későbbi lépésben. Ahonnan már nincs visszaút. És akkor már nincsenek adatbázisok sem, ergo bedőlt a DR teszt levelezési része, az meg azért túl nagy blamázs lenne.

Maradt a jó öreg magyaros megoldás, a buhera. Amit biztosan tudtam, az az, hogy az SCR beállításai a címtár konfigurációs névterében laknak, méghozzá az Exchange Services ág alatt. Mi lenne, ha megkeresném ezeket és úgy csinálnék, mintha lenne még SCR node a rendszerben?
Az első probléma ott volt, hogy honnan találom ki, hol vannak ezek az értékek? A DR telephelyen már nem volt SCR, de az élesen sem. Szerencsére volt hozzáférésem más, hasonló rendszerhez, beléptem, turkáltam. Hadd ne mondjam végig a folyamatot… itt van az eredmény. A beállítások a Storage Group objektumokon vannak (mindegyiken egyenként), méghozzá az MsExchangeStandByCopyMachine nevű változóban, a következő kódolással:

scrname.domain.name;1;xx:xx:xx;yy:yy:yy

Ahol az xx:xx:xx a replaylagtime, az yy:yy:yy pedig a truncationlagtime. Az 1-es értékét nem tudom – de őszintén szólva, nem is érdekel. Nem szándékoztam működő SCR-t létrehozni, csak behazudni a címtárnak, hogy az scrname nevű gépem valóban SCR target volt.

Óvnék mindenkit, hogy éles rendszerben ezeket az értékeket módosítsa. A Microsoft hivatalos álláspontja szerint az SCR replikáció paramétereit csak úgy lehet megváltoztatni, ha lebontjuk a replikációt, majd az új paraméterekkel újra létrehozzuk. Nyilván okuk van rá.

Hozzáteszem, a kockázat most is megvolt. De csökkent! Ha Eseutil-lal esek neki, akkor esély sincs rá, hogy a restore-storagegroupcopy esetleges plusz műveletei lemenjenek. Ha viszont behazudok egy SCR-t, akkor lehet, lefut a restore-storagegroupcopy, a továbbiakban meg már kell a fenének az SCR.

Kiválasztottam egy adatbázist, preparáltam, majd lefuttattam rá a restore-storagegroupcopy parancsot. Molyolt, molyolt… majd a várt 1 warning helyett kettő dobott. Ennek azért nem örültem olyan nagyon, tekintve, hogy a plusz figyelmeztetést olyan szinten voltam képtelen értelmezni, hogy még az se derült ki belőle, hogy lefutott-e a parancs? Vadul nekiálltam túrni a netet, de nem találtam megnyugtató választ. Lefuttattam még egyszer a parancsot… erre megint azt mondta, hogy nincs SCR. Háteztmeghogyan? Hiszen éppen az előbb hazudtam be, hogy van?
Vissza az adsieditbe… és tényleg nem volt ott a beírás. Valaki törölte. Tehát van egy érthetetlen warning-om és belefutottam egy önvédelmi mechanizmusba. Nem túl biztató.

Elvonultam gondolkozni.

A kulcs az, hogy a warning ellenére tényleg megcsinálta-e mindazt, amit tennie kellett? És csak utána törölte-e ki az általam beírt adatokat a védelme?
A törlés biztosan utólag történt, mert hibaüzenetet csak az újabb futtatáskor kaptam. De az a warning… Ráküldtem a parancsot a -verbose paraméterrel. Nem lettem okosabb. Végül úgy döntöttem, hogy ha tényleg képtelen lett volna elvégezni a dolgát – akár egy kezdeti ellenőrzés után is – akkor itt hibaüzenet lett volna, nem figyelmeztetés. Meg egyébként sincs más esélyem, csak ez.
Behazudtam a fenti string-et az összes storage group-nál, beírtam az alábbi parancsot, és malmoztam.

get-storagegroup | restore-storagegroupcopy -standbymachine scrname -force

Jó jel volt, hogy nagyon sokáig dolgozott.

Aztán nagy levegő, gyerünk tovább. DNS preparáció, AD jogosultságok állítása, majd jöhet a vízpróba. Cluster telepítése, a recovercms kapcsolóval. Prerequisit-ek ellenőrzése. 10 perc. Az életemből a tízszeresét vette el. Végül átszaladt rajta. Most jött a döntő pillanat: az első adatbázis felcsatolása.
Sikerült. Aztán szépen egyenként az összes.

Innentől meg már a jól ismert ösvényen mentünk tovább.

Megint back pressure

Emailben kaptam egy kérdést és ez ráébresztett arra, hogy talán érdemes lenne ejteni pár szót erről az ‘apróság’-ról.

Megint a back-pressure. Az ezerszer elátkozott. Rengeteget gyaláztam már, könyvben, is, blogban is.
Itt az ideje, hogy meg is védjem. Egy kicsit.

Az Exchange ESE adatbázis-kezelése tranzakciós alapú. Erről most nem akarok túl sokat írni, a lényeg az, hogy a friss, illetve a frissen használt adatok főleg a RAM-ban és a logfájlokban vannak, az adatbázisba csak akkor íródnak ki, ha az alkalmazás éppen ráér. Az elmélet gyenge pontja az, hogy mi történik akkor, ha éppen elfogy a tárterület az adatbázisok alól? A korábbi verziók védelméből létezik még két placeholder fájl a logkönyvtárban, de két lognyi hely… nem tudok olyan gyorsan pislogni, amilyen gyorsan az elfogy.
Ezért találták ki a back-pressure-t. Hogy amikor egy kritikus érték alá esik a szabad tárterület, az Exchange állítsa le tisztán az adatbázisokat (clean shutdown), mielőtt azok inkonzisztens állapotban dőlnének be (dirty shutdown). Megáll a levelezés? Bizony meg. De a tárterület bővítése után simán visszaindul.

Az elv oké. Nem azzal volt a baj. Hanem azzal, hogy a 2007-es RTM-ben – mely közel egy évig volt kint a piacon – ezt a kritikus értéket 4 GB-re tették. Azaz ha egy 10 GB-s partíciódból elfogyott 6, leállt a levelezés, a közepesen tájékozott admin pedig szaladgálhatott, mint pók a falon.
Nem csoda, ha ez a feature az első számú közellenség lett az Exchange rendszergazdák körében. Elméletileg, ha nem is egyszerűen, de lehet hangolgatni, ki is lehet kapcsolni – de ehhez ismerni kell az elvet. Itt követte el a második nagy hibát az MS. Én biztosisten, 40 pontos betűkkel írtam volna ki minden Exchange cikk fejlécébe, hogy vigyázz barátom, errefelé tombol a back-pressure.

Aztán az SP1-ben már finomítottak a gyakorlaton, a leállás már csak 500 MB alatt következik be, ami, valljuk be őszintén, teljesen rendben is van. Ellenben a tájékoztatás… az még mindig tré.

Ezen próbálok most javítani, egy extrém szopási lehetőség bemutatásával.

Ugyan írtam már róla, de talán annyira nem volt hangsúlyos a felvetés. Tudni kell, hogy az Exchange 2007 alatt már a queue is adatbázis! Azaz minden olyasmi elv is vonatkozik rá, mint ami a többi adatbázisra. Spec a back-pressure is!

Gondold el. Kis cég vagytok, nem akarsz túl nagy feneket keríteni a dolognak, az Exchange-t simán feltelepíted a C: meghajtóra. Az adatbázisok természetesen külön diszken vannak, szabad tárhely, mint a pelyva. Hol is van ilyenkor a queue? Hát a C:\Program files\exchrsrv alatt valahol.
Az élet vidáman megy tovább. A pagefile nő, nődögél, a patchek is zabálják a helyet a C:-n, meg ott van az az istentudja mennyi rejtélyes folyamat, melyek mind fogyasztják a rendszerpartíciót. De amíg megy a rendszer, a fene sem veszi észre. Aztán egyszer csak megáll a levelezés.
Az adatbázisoknál bőven van hely. Oké, a C:-n annyira nem, de kit érdekel most a C:?
Hát például a művelt Exchange admint.

When the back pressure limits for hard disk drive space utilization are set to their default levels, the hard disk drive that stores the message queue database on an Edge Transport server or Hub Transport server must always have a fixed amount of free hard disk drive space. In Exchange 2007 RTM, the amount of required free hard disk drive space is 4 GB. In Exchange 2007 SP1, the amount of required free hard disk drive space is 500 MB. If the available free space is less than the required amount of free hard disk drive space, the hard disk drive utilization level is considered high. Therefore, all message flow stops. In that case, you must follow one of these steps:
– Relocate the message queue database to a different hard disk drive that has more free space. For more information, see How to Change the Location of the Queue Database.
– Increase the values of the PercentageDatabaseDiskSpaceUsedHighThreshold, PercentageDatabaseDiskSpaceUsedMediumThreshold, orPercentageDatabaseDiskSpaceUsedNormalThreshold parameters.
http://technet.microsoft.com/en-us/library/bb201658(EXCHG.80).aspx

Durva pofon, nem?

Persze elkerülhető lett volna, ha:

  • Az Exchange alkalmazást nem a C:-re telepíted, hanem egy külön alkalmazáspartícióra, mondjuk D:-re – és ezt a partíciót nem is használod semmi másra. Ekkor a szabad hely csak egy extra nagy levéltömeg bezúdulásakor lenne képes elfogyni.
  • Használsz valamilyen monitorozást. Ne mondd azt, hogy a SCOM baromi drága. Akkor tegyél fel linuxon egy nagios-t, abszolút ingyen van és – többek között – a szabad tárterületet is tudja monitorozni.
  • Legfőképpen pedig ismerd meg az eszközt, amit használsz. Tudod, a törvény nem ismerete nem ment fel a következmények alól.

Már a Google is megbuggyant?

Egyre inkább törzshasználója leszek a Google Office rendszernek. Ez nem baj, ami praktikus, azt célszerű használni is. Kezdődött a Google Calendarral, mellyel végre sikerült egybeintegrálni a család összes tagjának egyéni Outlook naptárait és végre körtelefonálgatások nélkül tudok szinházi programot szervezni, nyaralásokat, rövidebb kirándulásokat tervezni. A következő lépés a Google Reader megjelenése volt, ezt végre már tudom PDA-n, mobilon is olvasni. A FeedDemon itt szerepelt le csúnyán. (Meg a hibás megjelenítésen, meg a lokális keresés hiányán, meg ugye külön alkalmazás, szemben az állandóan nyitva tartott böngészővel.) Aztán belépett a használt alkalmazások közé a Google Documents. Ha valamit gyorsan fel kell írnom valahová és azt szeretném, hogy mindig kéznél legyen, akkor ez majdnem(1) tökéletes. (Gondolatok, linkek szakmai írásokhoz, témák, melyekről majd írni akarok a blogban – bármelyikben(2) – de még rajzötletek is simán elférnek.) Elméletileg lenne erre tökéletes megoldás is az MS-től: a Onenote, PDA szinkronon keresztül. Csak éppen tré. Nem működik. (Ha belejavítok egy már létező és korábban összeszinkronizált szövegbe akármelyik gépen, a módosítás nem megy át a másikra. Ha egy bejegyzés átszinkronizálódott egy másik gépre, akkor már csak úgy lehet törölni, ha off-contact állapotban törlöm mindhárom eszközről.) Az Office-ba épített Notes… azt meg hagyjuk.

(1) Csak azért majdnem, mert nem tudom a PDA-ra úgy rászinkronizálni, hogy a doksik offline is meglegyenek.

(2) Elméletileg erre jók lennének a blogadmin felületek is, de mégsem. Kényelmetlen elmenni az oldalra, belépni, aztán beírni a cuccot a draftokhoz. Ráadásul ekkor keverednek a már kész, de még nem publikált, illetve a még csak piszkozat írások. Inkább fordított folyamat zajlott le: a blogpiszkozatok kerültek át a Google Document-be.

Szóval így álltunk. Egészen pár nappal ezelőttig, amikortól is a következő képet kapom, ha átváltok a Calendar-ra.

Nagyítás

Hiába vártam utána akármennyit is. Minden más Google alkalmazás tökéletesen működik. Kipróbáltam más böngészőből is: IE alatt megy a Calendar. Átmentem más gépekhez. Végül se az otthoni, se a munkahelyi, se a tabletpc nem tudta elérni a Calendar-t Firefox-ból, ellenben mindenféle létező egyéb böngészőből simán ment.
Végiggondoltam a dolgot. Végülis, nekem nem olyan fontos, hogy a háttérben állandóan figyelő Google Office Firefox-on fusson – egyik funkciója sem FF plugin specifikus.

Emiatt döntöttem a Chrome mellett. (Ha már Google.)

Az otthoni két gépre simán fel is szaladt, kicsi, gyors – és mivel csak egy célra használom, nem érdekel, hogyan viselkedik úgy általában a neten.

Csakhogy. A munkahelyemen már megráztam a pofonfát.
A Chrome ugyanis nem olyan, hogy letöltöd és lefuttatsz egy exe fájlt. Az interneten keresztül akar telepíteni. Initializing… initializing… nem sikerült neki. Feldobott egy hibamegoldó ablakot, de a tippek nem segítettek. Jöhetett a jó öreg proxycfg -u parancs, de most hiába. Az se sokat segített, hogy a Chrome oldaláról le lehetett tölteni egy 500KB-os fájlt, mert ez csak trailer. Később ez se tudott túljutni az inicializálós fázison.
Szétnéztem a neten… és megtaláltam ezt. Hát… azért ez elég rendesen gáz. Habár a hiba nem pont ez, de van az oldalon egy link egy _teljes_ telepítőkészletre. Letöltöttem. Elindítottam. Aztán ez is beleveszett az inicializációs folyamatba.
Továbbolvastam a hozzászólásokat. Volt még ott link egy könyvtárra, amelyben komplett Chrome installációk voltak becsomagolva… de valahogy az útvonal neve (buildbot) nem tetszett. Vártam, vártam… aztán ráböktem arra a piros ikszre az inicializálós ablak jobb felső sarkában. Erre feljött az üzenet, hogy a telepítés sikeres volt. ???
Elindítottam. Működött. Beírtam egy címet. Közölte, hogy nem éri el a weblapot.
Aha. Proxy.
Nézzük, proxy konfigurálás. Rákattintottam a gombra – és behozta az IE connection paneljét.
Itt estem le a székről. Hát annyira szarul megy már a Google-nek is, hogy nem fér bele a mérnök munkaidejébe egy beállítóablak legyártása? Hogy bekérje, milyen proxy is van?
De ezzel még nincs vége. Ugyanis nálam az IE is be van állítva, tehát elméletileg át kellett volna tudnia venni az értékeket. Csak éppen a cégnél szkript adja fel az éppen aktuális proxy-t. És azok a zseniális fiúk a Chrome-nál ezt már nem bírták lekezelni.
Így most választhatok:

  • Bekonfigurálom az Internet Explorert egy fix proxyra, elvesztve ezzel a szkript okozta rugalmasságot.
  • Törlöm a francba a Chrome-ot, és – a Firefox hiba miatt – a nagyobb erőforrásigényű Internet Explorert használom a Google Office-hoz. Vicces. Meg persze reménykedek, hogy valakinek eszébe jut majd berakni egy adatbekérő panelt a Chrome proxy beállításaihoz.

Ki mivel szív?

Ez anno a régi Technet magazin egyik népszerű rovata volt. (Csak ott az utolsó szót egy szivecske rajz helyettesítette.)

Az egyik kedvenc rovatom volt: a mai napig úgy tartom, hogy egy hiba behatárolásából, megoldásából sokkal többet lehet tanulni, mint egy tisztán elméleti fejtegetéseket tartalmazó cikkből. (De a legtöbbet a kettő kombinációjából: az az ideális, ha a szerencsétlen rendszergazda miután leírta a megoldást, odaírja/odalinkeli mellé az elméletet is.)

Az egyik jó hír, hogy Jim Mcbee-nek eszébe jutott végre a blog jelszava(1). Egyből el is eresztett 8 új írást. A másik jó hír, hogy az egyik egy igen érdekes hibát és annak megoldását tartalmazza.

(1) Illetve beindult az RSS feed-je. Mert ahogy látom, írni írt… csak az RSS reader nem látta.