|
|
|
Author: |
SUF |
Created: |
2008. 11. 26. 10:28 |
 |
|
SUF Blog |
By SUF on
2006. 09. 22. 12:47
Átmenetileg kiraktam az internetre a tegnapi webcast anyagát. Nem sokára a Microsoft oldalán is meg fognak jelenni ezek a fájlok.
Powerpoint Prezentáció:
http://www.it-pro.hu/Default.aspx?tabid=95&id=60
Powerpoint Demo:
http://www.it-pro.hu/Default.aspx?tabid=95&id=61
Előadói megjegyzések (pdf):
http://www.it-pro.hu/Default.aspx?tabid=95&id=62
Lassan jönnek a scriptek is, csak az egyiken még kicsit fényezek.
[Update 2006/09/22 16:53]
Kiraktam a scripteket is végre:
http://www.it-pro.hu/Default.aspx?tabid=95&id=63
[Update 2006/09/25 16:16]
Kikerültek az anyagok a Microsoft weboldalára. Mostmár a Webcast felvétele is kint van:
http://www.microsoft.com/hun/webcast/default.aspx?id=07c01307-e5b7-4918-bd40-d6e6a6d16011
|
By SUF on
2006. 09. 22. 11:28
Tegnap megtartottam a mentésről és visszaállításról szóló webcastomat. A visszajelzések szerint nem volt csúfos bukás a dolog ugyanakkor én nem vagyok elégedett magammal.
Ma reggel megint bejött: egy Murphy nevezetű alak összes fel és lemenőinek folyamatos emlegetésével kezdtem a napot.
Előzmény:
Úgy két hete az egyik szerverünk RAID-jében kikönyökölt az egyik vinyó. Ki is cseréltem valamire amit épp a fiókban találtam, újra is építette, de a fiókból berakott disk-et nem akartam véglegesen bennehagyni, ráadásul némi kapacitás bővítés is ráférne az egyedre így megrendeltem egy teljes garnitúra új vinyót, melyek meg is jöttek.
Ma reggel 9 körül:
Lementem a szerver szobába, hogy elkezdjem egyesével kicserélni a disk-eket amit ugyebár on-line meg tudok tenni. Valamit meg akartam nézni a gépben belül ezért kihúztam a rackből. Figyelmetlen voltam, túl rövid volt a 230-as kábel így a gépet sikerült áramtalanítani. Amikor visszakapcsoltam egy kék képernyős nemindulással fogadott (gratula Murphy).
Na boldog vagyok, kipróbálhatom, hogy én mennyire vagyok jó abban amiről tegnap dumáltam.
9:23:
Először is ASR kilőve. Az előadásban sem beszéltem róla, mert nem használom és időm sem volt foglalkozni vele (úgy látom mindenképp utána kell néznem)
Gép boot CD-ről, Recovery Console elindít. Ez az a dolog amit a büdös életben nem használtam. Rájöttem, hogy ma sem fogom. Se az AD Admin jelszavát, se az AD Recovery Admin jelszót nem fogadja el (ja nem mondtam még, a gép hogy könnyítsünk a helyzeten egy DC).
9:46:
Megpróbálom a CD-ről a telepítsünk és reparáljunk opciót. Sok bizodalmam nincs benne, mert nekem még sosem működött (nagy gáz persze nincs, mert legrosszabb esetben újratelepít az egész és mentésből visszatölt. Ez sem tarthat sokáig, mert ugye disk nem sérült és éles szerveren mindig külön tartom a boot partíciót, így csak a c-t kéne visszatölteni).
10:18:
Csoda történt. Egyszer az életben működött a repair. Elindult az egész.
10:32:
Települnek újra a biztonsági hotfixek.
11:06:
Hotfixek fenn, újraindulunk.
11:16:
Működik a dolog. Most nekikezdek a vinyócserének.
|
By SUF on
2005. 11. 23. 17:46
Előre szólok, csak az olvassa el akinek van türelme hozzá. Eléggé hosszúra sikeredett. Én részemről sokat tanultam ebből a történetből.
Alapvetés:
Van egy kedves felhasználónk akinek kézen-közön eltűnt a mailboxa. Vissza kéne állítani, de..
1. Összesen valami 3 hetes mentés van róla (a köztes 3 hétről nem is beszélünk mert az kategórikusan nincs meg)
2. Az egész dolog nem olyan kritikus, hogy bármi módon hajlandó lennék az éles szervert veszélyeztetni miatta.
3. Sérti az önérzetemet, ha nem tudom megcsinálni.
4. A kollégái mostanában többször hívtak, hogy próbáljam megoldani (az eset mintegy másfél hónapja kezdődött)
Előzmények:
Természetesen az Exchange rendszergazdák szokásos bajával küzdök, hogy cég szinten nem lehet kemény limitet beállítani a felhasználóknak a mailbox méretére, a 16GB-os korlát be van vasalva az Exchange 2003 Standard Editionbe (ebben az időpillanatban az SP2 még nem létezett). Annak idején írtam egy scriptet ami hetente egyszer elküldi a felhasználóknak, hogy túllépték a limitet és töröljenek, de sajnos ez egyre inkább hatástalan.
Egy költözés előkészületei zajlottak éppen aminek kapcsán a szóban forgó Exchange szerverre néhány plusz mailboxot át kellett költöztetni és akárhogy számoltam nem volt ehhez elég hely (az Enterprise Edition beszerzése szóba sem jöhetett anyagi okokból).
Ide tartozik még, hogy a helyszűkére való tekintettel levettem a dumpster törlési idejét egy napra, valamint a törölt mailboxok megtartását is egy napra (mint később kiderült ez utóbbi hiba volt).
Ráadásul a gépnek volt némi Exchange adatbázis hibája is egy valamikori hibás rendszerleállítás miatt (az adott cég előző rendszergazdájának műve).
Ezekből következően két feladat várt rám:
1. Adatbázis reszelés
2. A felesleges mailboxok (elment dolgozók) törlése
Miután nem divat tudatni az informatikával, ha valaki kilép (azért, hogy belépett és legyen mindene azonnal természetesen verjük az asztalt, de nem takarítunk magunk után), elég nehéz kideríteni, hogy ki az aki már nincs. Csináltam egy szép hosszú listát arról, hogy ki van a rendszerben és kiadtam az illetékeseknek, hogy mondják meg ki az aki már nem dolgozik itt. Megkaptam a választ a listámra, arra a kérdésemre, hogy a törlésre kijelölt mailboxokat meddig kell még megtartanom, egy határozott "azonnal törlendő" választ kaptam.
A történet itt kezdődik:
Megpróbálom időrendben, dátum szerint felidézni az eseményeket, bár a kezdetek már az idő homályába vesznek.
Egy szombat reggel
Észreveszem, hogy az egyik Exchange szerver adatbázisában pici hibák vannak. Ezt valamikor reparálni kellene, de mostanában esélytelen. Költözés lesz, stb. Csinálok egy gyors ExMerge exportot a pst-kről, majd ha lesz rá lehetőség a költözés után, akkor mehet a repair.
Ezt az ExMerge-es dolgot megismétlem a következő hetekben néhányszor, hogy ne legyen gáz.
Egy későbbi szombat reggel.
Mennyivel jobb is Exchange-t reszelni, mint az ágyban fetrengeni még néhány órát
ExMerge Mailbox exporttal indítunk.
Valamikor délelőtt Exchange Store leállít.
Repair.
Elmegyek ebédelni.
Kapok egy hisztis telefont az egyik kollégától, hogy nem tud dolgozni (meg kell jegyeznem, hogy a szombat nem munkanap nálunk). Megegyezünk, hogy valamikor délutánra lesz szerver.
Minden sikerül, béke van.
Kitörlöm a megegyezett felhasználókat. (ezek ugye hétfőre nyomtalanul eltűnnek a már említett egy napos beállítások miatt)
Következő hétfő este
Este csinálok még egy ExMerge-es backupot, majd a meglévő korábbi hasonló mentés fájljait felülírom az újonnan keletkezettekkel. Na itt csúszik el a dolog. Volt egy felhasználó akinek nem kellett volna megszüntetni a hozzáférését (láthatóan pontos listát csináltak nekem). Ezt a felhasználót a kedves kollégám ennek a hétfőnek a reggelén újra létrehozta. Én pedig este felülírtam az üres pst fájlal a telit (ez ugye nem fordult elő a megszüntetett és újra létre nem hozott felhasználókkal, hiszen nekik ezen az estén nem keletkezett pst fájljuk)
Néhány nappal később
Kiderül, hogy gáz van. El kezdek gondolkozni, hogy mit lehet tenni. Miután a mentésünk rotációs jelleggel diszkre zajlik, már nem volt meg olyan mentés amiben még meg lett volna a keresett adat. Pontosabban valamikor szeptember végén lecseréletem a mentésre szolgáló vasat és van 2db 250GB-os vinyóm amin rajta lehet valami korábbi mentés. Rajta is volt. Leszedtem a fájlokat. Ezt ugyanakkor az éles rendszerre még Recovery Storage Groupba sem merem visszatölteni.
2005.11.14
Végre nekiállok a visszatöltésnek. Telepítek egy virtuális gépet, exchange rá, próbáljuk visszatölteni.
1. Sima restore. Nem ment. 9635-ös hibát kapok rá, merthogy nem találja az AD-ben az azonos GUID-ű Storage Groupot.
2. Recovery Storage Group létrehoz. Override RS bekapcsol. A hiba változatlan
3. ADSI Edit, storage group létrehoz, GUID beír, nem megy, közli, hogy az attributum tulajdonosa a rendszer
4. ADSI Edit elindít rendszer joggal (AT parancs), változatlanul nem engedi a GUID-ot módosítani.
Feldobom az ügyet a levlistára, keresgélek a guglin semmi értelmes válasz.
Egyenlőre tanácstalan vagyok.
Kapok egy telefont a törölt mailbox tulajdonosának egy kolléganőjétől, hogy nagyon kellenének az adatok (ez eddig nem volt ennyire fontos, mindegy). Mondom neki, hogy dolgozom rajta de nem sok esélyt látok.
2005.11.16
A Microsoft termékbejelentésén vagyok amikor jön egy telefon a mailboxtulajdonos főnökétől, hogy mi a helyzet. Neki is elmondom, hogy megteszek mindent, de eléggé esélytelen az ügy.
Néhány napig nem volt időm foglalkozni vele, majd ...
2005.11.21.
Megint volt egy kis időm nekikezdeni a dolognak. Feltelepítettem újra a virtuális gépet. Egy cikkben a neten találtam valami halvány utalást arra, hogy a gép nevének, stb. azonosnak kell lennie a restore-hoz. Nosza, csináltam egy olyan környezetet amiben a domain, a gép neve, az Exchange org neve, az Administrative group neve (ez utóbbi trükkös, mert az első admin group nem nevezhető el egyszerűen. System manager feltelepít az Exchange előtt, Administratice Group létrehoz, majd Exchange telepít) azonos az eredetivel.
Bentről magammal hoztam haza az adatbázis backupot
Nekiáltam visszatölteni az adatbázist (Recovery Storage Group nélkül, registry buhera nélkül) és láss csodát elkezdte visszarakni. Gőzerővel visszatöltöttem az adatbázist.
Miután be voltam sózva, SSH-n elkezdtem letölteni bentről a log backupok egy részét.
2005.11.22.
Innen már órára bontva megy a történet
05:51 - Felkeltem.
Reggelre lejött bentről még néhány log backup elkezdem visszatölteni őket. Sikerül is azokat amik itt vannak márt, a többit majd bent a munkahelyemen.
08:37 - Beértem
Folytattam a logok visszatöltését.
10:47
Elérek az utolsó backup set-ig, erre közli, hogy sérült, on media catalog kikapcsol, backup set újrakatalogizál, visszatölt, a visszatöltés végénél közli, hogy kéri a set második felét, lelövöm, elkezdi visszajátszani a logokat és ...
elszáll. 
Kapok egy 412-es ESE hibát melyben közli, hogy nem tud olvasni egy log fájlt. Naná, a sérült mentés utolsó fájlját.
Letörlöm a hibás fájlt, visszatöltöm az utolsó előtti mentést újra. Elkezdi visszajátszani a logot. Megint elszáll.
Most egy 904-es ESE Backup hiba. Közli, hogy nem talál egy fájlt. Persze azt amit letöröltem.
Na mindegy, ha idáig egyszer már eljutottam, nem adom fel könnyen (nincs sok kedvem újrakezdeni). Fel akarom mountolni a Store-t. 619-es ESE hiba, nem fejezte be a restore-t. Irány a KB. 810099 -es cikk. Kell egy eseutil /cc annak a könyvtárnak a nevével ahol a restore.env található.
Elindítom az eseutilt, ugyanúgy közli, hogy nem talál egy logfájlt és kiírja, hogy E000296b.log -tól E0002F51.log -ig akarta visszatölteni. Hümm. Feltételezem, hogy ezeket az adatokat a restore.env-ből vette. Nekiugrottam ez utóbbinak egy hexeditorral, megkerestem a kérdéses bejegyzést, kijavítottam a 2F51 hex-át 2F50 hex-ára, mert ugye ezt az utolsó fájlt töröltem.
11:34
Eseutil /cc másodszor. Most elindul... várunk. Nézem az Event Logot. Átlag 3 percenként dolgoz fel egy új logfájlt. Kiszámoltam a cirka 10 gigányi logot mintegy 5 nap alatt fogja feldolgozni. Vicces lesz...
15:30
Elindulok a tanfolyam irányába (Év eleje óta egy Informatikai Biztonsági Szakértő című tanfolyamra járok. A mai az utolsó alkalom, majd valamikor decemberben vizsga). Természetesen az eseutil még nem végzett, de gyorsabban halad mint számítottam.
19:30 körül
Visszaérek a tanfolyamról (mint sokszor most sem bírtam végigülni)
Kiderül, hogy az eseutil közben elszállt egy -567 -es hibával. Semmi okosat sem találok rás a KB-ben, egyszerűen csak feltételezem, hogy rászaladt valami hibára az adatbázisban (elvégre az adatbázis mentés amiből dolgozom egy hibás darabról készült). Ez most nem izgat. Sikerült visszatöltenie a logok jó felét.
19:42
Teszek még egy ványatag kísérletet arra, hogy visszajátszam a hibás log utániakat (Hex editor a restore.env-en, eseutil /cc) de ez természetesen nem sikerül.
19:50
Megpróbálom elindítani az adatbázst, természetesen nem megy. Közli, hogy nem volt hard recovery.
19:55
Adatbázis reparálás eseutil /p elindul
20:30 körül
Lelövöm a virtuális gépet, hazamegyek
20:55
Hazaérek, virtuális gép elindít eseutil folytatja (mekkora találmány ez a save state dolog, nem kell kivárni a dolgokat, bárhol bármikor megszakítható és folytatható). Ma már nem foglalkozom vele, majd holnap.
2005.11.23
02:10 - Felébredtem
Megint azon hülye napok egyike amikor nem tudom rendesen kialudni magam.
Folytassuk az Exchange reszelést. Ránézek a gépre: eseutil befejezte. Indítsunk adatbázist. Nem megy 1088-as hiba az Event Logban. Nem lepődök meg, erre számítottam. Tegnap este még kinyomtattam egy rakás KB cikket és köztük a 324606 -ost ami erről szól. Letöltöm a LegacyDN.exe -t játszom vele egy kicsit. A doksi zavaros. Sikerül gyártanom egy logot amiből kiderül, hogy mely pontokon kell megváltoztatnom a LegacyDN értékét, de megcsinálnom nem sikerül vele. Nem baj. ADSI Edit elővesz, LegacyDN-ek átír (7 helyen).
02:59
Exchnage szolgáltatások újraindítása. Nem indítja el a Public store-t (erre számítottam, mert ugye most a Public Store LegacyDN értéke rossz), de nélküle megleszek. Elindul a Mailbox Store. Hurrá, célegyenes! 
Látom a mailbox-okat a System Managerben.
03:12
ExMerge elindít, nem látja a mailboxokat. Ok, ez rendben van. A mailboxok alapvetően disconnected állapotban vannak, csak én ezt nem látom a System Managerben így nem tudom felhasználóhoz csatolni (a Reconnect Mailbox szürke). Ha megvárnám az Exchange rendes napi nagytakarítását akkor látnám az eredményt, de nem akarok erre várni. Irány a KB. A 261142 -es cikkből kiderül, hogy a Run CleanUp Agent az én barátom. Létrehozom a felhasználót, hozzácsatolom a mailboxot.
03:24
ExMerge újra, elkészül a pst. Végeztünk. 
Írom a cikket. Kiszedtem minden adatot a virtuális gépből ami kellett.
04:50
Ünnepélyes shutdown. Virtuális gép megy a levesbe.
Remélem nem túl zavaros a dolog. Darabokban írtam az elmúlt másfél napban.
|
By SUF on
2005. 11. 11. 14:38
A hét eleje óta napja nem megy a weboldalam. Csak most vettem észre mert az elmúlt időszakban se web oldalt reszelni, se fejleszteni nem volt időm. Ma átraktuk Subicz Peti segédletével egy másik szerverre, remélem, hogy működni fog. Egyenlőre azt várom, hogy a DNS bejegyzés replikálódjon.
|
By SUF on
2005. 10. 17. 17:12
Eddig MSDN Enterprise előfizető voltam. Azt tudom már egy ideje, hogy az MSDN Enterprise megszűnik és helyette a Visual Studio 2005 Team Edition for SW Developers with MSDN Premium-ot fogom kapni. A váltás novemberben történik és már előre dörzsültem a markom (főleg az MSDN Premiumra. Szerettem volna belőle ezt-azt hivatalosan tesztkörnyezetnek). Gondoltam, majd valamikor november végén történni fog valami. Meglepetésként ért, hogy ma reggel megtaláltam az első MSDN Premium DVD csomagot az asztalomon. Hurrá! 
Gyorsan felmentem a Subscriber Downloads-ra. Itt ugyan még azt írja a fejlécben, hogy MSDN Enterprise, de a tartalom már a bővített. 
|
By SUF on
2005. 10. 17. 16:53
Az elmúlt hetekben nem írtam. Miért is? Nem csináltam semmi olyat amiről tudtam volna írni. Van egy kupac félbehagyott projectem. Remélem be tudom fejezeni őket és akkor lesz miről írni.
Addig is a ma reggeli küzdésről:
Reggel nyolckor amikor épp indulnék dolgozni, csörög a telefonom és az egyik cégünk egy megfelelően agilis dolgozója hív. Természetesen nem kéne tudnia a telefonszámom és természetesen nem én vagyok az adott cég rendszergazdája.
Az a baja, mint a múltkor amikor hétvégén nem tudott dolgozni (épp Exchange karbantartottam, mert a Store repülni tanult. Szeretem az Exchange JET motort). Gyorsan eltanácsoltam az illetékes rendszergazda kartársnőhöz. Persze közben beindult a gyomorideg, hogy mi lehet a gáz.
Beérek. Az egyik kedves kartárs közben újraindította a szervert, az Exchange már megy, de levél se be, se ki. Belenézek az Application logba, egy rakás hibaüzenet. Kicsit csodálkozom, mert a System Attendant és a Metabase Update hisztizik, a storenak semmi baja. Ilyet nem szokott.
Rákeresek a neten az Event ID-kra. Nem találok semmi értékelhetőt. Csontideg.
Intermezzo: Elmegyek tárgyalásra, mert ez akkor is fontosabb ha az egész rendszer áll.
Óra múlva vissza.
Valami hátsó gondolattól vezérelve bele nézek a Directory Service logba (egy hete költözött a szóbanforgó site, miután a bérelt vonal nem készült el kénytelen voltam VPN-t csinálni. Hátha az okozza a gondot). KCC hiszti hegyek. Nyomon vagyok, ez okozhatja az Exchange bajait.
Mióta is tart ez a dolog? Pénteken volt egy tervezett leállás egy bejelentett áramszünet miatt, azóta nem megy. Persze azóta nem tudtam ránézni a gépre, mert szerda este óta vidéken voltam.
Miután volt némi DCOM jellegű gond az aktuális biztonsági frissítésekkel, elkezdem kérdezni a rendszergazdákat, hogy nem rakták-e fel őket az újraindítás kapcsán. Mindenki tagad.
Megnézem a gépet, nem kerültek fel.
AD Sites & Services, replikáljunk kézzel. Csúnya hibaüzenet arról, hogy az endpoint mapper betelt (ez RPC gond lehet). Lehet, hogy a másik oldalon lévő DC amivel replikálni próbál okozza a problémát (ráadásul ez utóbbi veszi át a netről a leveleket is, a levelezés meg ugye nem megy). Nem gondolkozunk, újraindítjuk ez utóbbit. Meggyógyul a levelezés. Hurrá! 
Vagy mégsem? A KCC hibák maradnak. 
Na gondolkozzunk. Annak idején korlátoztam és máshova raktam az RPC portjait, hogy legalább valamennyire kezelni lehessen a cégek közötti tűzfalon. Ezzel minden rendben?
Belenézek a gép registry-jébe. Nini, hiányoznak az RPC bejegyzéseim. Bepakolom őket, restart, működik. Hurrá! 
Mostmár csak azt szeretném tudni, hogy:
1. Én voltam annak idején olyan hülye, hogy ezek a bejegyzések kimaradtak ennek a gépnek a konfigjából, vagy azóta tüntek el?
2. Ha én voltam a hülye, akkor hogy lehet az, hogy egyáltalán működik ez? Április óta megy és egy hangja nem volt ami RPC problémákra utal.
Na mindegy. Mázlistának érzem magam, gyorsan sikerült megoldani. 
|
By SUF on
2005. 09. 28. 13:05
Sok más egyéb mellett elkezdtem belepiszkálni némi statisztika gyártásba az Exchange Store-ra vonatkozóan. Miután levelekre, csatolmányokra időpontokra vonatkozó adatokra van szükségem, kénytelen vagyok beleolvasni a mailboxokba. Ezt tehetném WebDav-al, vagy az Exchange OLE DB providerrel ADO-n keresztül. Ez utóbbit választottam, mert ezzel már játszottam korábban. Úgy gondoltam, hogy tesztelgetni egyszerűbb a kliens oldalon, így elindítottam az első kis tesztprogramomat, ami valami ilyesmi volt:
BaseURLStr = "http://mail1/exchange/zoli/";
Folder = "Inbox";
var SelectStr;
var ExchConn = new ActiveXObject("ADODB.Connection");
var ExchRS = new ActiveXObject("ADODB.Recordset");
SelectStr = "SELECT \"DAV:displayname\", "+
"FROM SCOPE('SHALLOW TRAVERSAL OF \"" +
encodeURI(BaseURLStr + Folder) + "\"') "+
"WHERE \"DAV:ishidden\" = false";
ExchConn.Provider = "ExOLEDB.DataSource";
ExchConn.Open(BaseURLStr);
ExchRS.Open(SelectStr, ExchConn);
for(;!ExchRS.EOF;ExchRS.MoveNext())
{
WScript.Echo(ExchRS.Fields("DAV:displayname").Value);
}
ExchRS.Close();
ExchConn.Close();
Meglepetten tapasztaltam a következő hibaüzenetet:
ADODB.Connection: Provider cannot be found. It may not be properly installed.
Hoppá, ezek szerint az ExOLEDB provider csak az Exchange szerveren van telepítve. Elkezdtem túrkálni a neten, hogyan lehetne felrakni ezt a kliensre. Arra jutottam, hogy sehogy. Helyette az MSDAIPP providert lehet használni. Ezek után a fenti kód egyetlen sorában módosul:
ExchConn.Provider = "ExOLEDB.DataSource";
helyett
ExchConn.Provider = "msdaipp.dso";
Ezzel a kliens oldalról is el lehet érni a szervert, mindösszesen arra kell odafogyelni, hogy csak a http:// uri-t szabad használni a file:// uri-t nem.
Infók hozzá:
|
|
|
By SUF on
2005. 09. 22. 9:57
Ilyet nem szoktam írni, de mostmár piszokul bosszant. Ismét rájöttem, hogy az internet szolgáltatónk a T-Offline (http://www.domain.hu/domain/domainsearch/?domain=t-offline&tld=hu). Megint nincs netünk, bérelt vonalon rengeteg pénzért. Unom. (Ezt a PDAmról írom)
|
By SUF on
2005. 09. 21. 15:24
Egy régi problémám volt az, hogy hogyan találjunk meg egy felhsználót az Active Directoryban az e-mail címe alapján. Volt erről egy hosszú thread a technetklub levlistán ( http://listmanager.technetklub.hu/read/messages?id=122959) amiből az derült ki, hogy valamelyik proxyAddress alapján nehéz megtalálni a felhasználót, ráadásul lassú is. A probléma alapja, hogy azt gondoltom (gondoltuk többen), hogy a proxyAddresses propertyben nem lehet keresni mert az egy multivalue property. Már tervezgettem, hogy írok valami szolgáltatást a dologra. Egy progi megadott időközönként végigtúrja az AD-t épít belőle egy adatbázist amiben utána én tudok gyorsan keresni.
...use objectCategory rather than objectClass because objectCategory is single-valued and ideal for servicing search requests...
Várjunk csak, ezek szerint lehet multivalue propertyben keresni. Kipróbáltam. Íme az eredmény:
var SearchMail = "test@domain.hu";
var ADConnect = new ActiveXObject("ADODB.Connection");
var ADCommand = new ActiveXObject("ADODB.Command");
var rootDSE, ForestRoot, ADRS;
rootDSE = GetObject("LDAP://rootDSE");
ForestRoot = rootDSE.Get("rootDomainNamingContext");
ADConnect.Open("Provider=ADsDSOObject;");
ADCommand.ActiveConnection = ADConnect;
ADCommand.CommandText = "
|
By SUF on
2005. 09. 20. 12:10
Az elmúlt két hétben szabadidőmben leginkább a már korábban emlegetett listaszerverrel kapcsolatos kódokat, adatbázist reszelgettem. Sikerült összehoznom egy egész jó kis storage engine-t (kidobálja a duplikált csatolmányokat, opcionálisan tömörít, opcionálisan fájlban, vagy az adatbázisban tárolja a levelet). Most elkezdtem játszani a levél fogadással és küldéssel. Ennek kapcsán az egyik igen érdekes probléma, hogy hogyan kezeljük a válaszleveleket, a thread-hierarchiát. Azt látom, hogy a lyris hol megtalálja az összetartozó darabokat, hol nem. Én szeretném elérni, hogy ez a dolog ne legyen ennyire esetleges. Egyenlőre a következő ötleteim voltak:
1. A levél fejlécében lévő Reply-To: mezőbe nem az adott levlista címét írom, hanem valamit amivel azonosítani tudom a levelet. Ilyesmire gondoltam a_levél_adatbázisbeli_guid-ja@lista_domainneve . Ez ugye reply esetén egész pontosan azonosítja az eredeti levelet, ugyanakkor ha valaki normál levél küldéshez véletlenül ezt a címet használja akkor az alaposan összekavarhatja a dolgokat. Ezt az ügyet egyenlőre félretettem, arra az esetre ha nem lesz más megoldás.
2. Használom az RFC-ben megadott Message-ID:, In-Reply-To:, References: mezőket. Az RFC-822 -ben úgy tűnik, hogy ez opcionális az RFC-2822 -ben mintha kötelező lenne. Biztos az én angol tudásommal van baj, de ebből nem tudom eldönteni (23.oldal 3.6.4-es pont):
Though optional, every message SHOULD have a "Message-ID:" field. Furthermore, reply messages SHOULD have "In-Reply-To:" and "References:" fields as appropriate, as described below. ...
Azt értem, hogy igazából ezt kellene használni, de megnézve a lyris-es leveleket igen kevésben találtam meg az In-Reply-To: mezőben a szülő levél azonosítóját, ráadásul az Exchange 2003 / Outlook 2003 páros sem teszi bele a levélbe.  (Valaki megmondhatná, hogy valójában ezt kötelező-e megcsinálni és ha igen akkor az Exchange/Outlook miért nem teszi? Vagy ha teszi akkor nekem miért nem?)
3. Találni valami olyan fejlécmezőt ami a levél továbbítását nem befolyásolja, viszont reply esetén benne marad. Ezt kipróbáltam egy általam kreált X- mezővel, de nem működött.
4. Belegenerálok valamit a levél szövegébe és amikor visszajött akkor megkeresem benne. Ezzel több bajom is van. Mi van akkor, ha több ilyen van benne? Mi van a digitálisan aláírt levelekkel (ugye ezeket nem szabad módosítani, ezt sajnos nem minden listaszerver tartja be).
Egyenlőre tanácstalan vagyok, keresem tovább a megoldást.
|
By SUF on
2005. 09. 18. 19:26
Ma elszórakoztam egy rég problémám megoldásával. Az oldalamon két helyen is használtam a WMI repositoryba fordított mof fájl olyan eseménykezelőkhöz amik a rendszer újraindítása után is tovább működnek:
http://www.gomori.hu/elog_db_hu.htm
http://www.gomori.hu/storesize_hu.htm
Felmerült az a kérdés, hogy mi van akkor, ha el szeretnénk távolítani az így regisztrált eseménykezelőt. Eddig csak egy Microsoft WMI adminisztrációs eszközzel, kézzel tudtam eltávolítani. Most elkövettem egy eszközt ami képes ezt eltávolítani. Majd később az oldalra is ki fogom rakni. Ez a fentiek közül az elsőhöz készült.
A kód innen tölthető le
|
By SUF on
2005. 09. 13. 20:04
Pár napja írtam már a fenti címről. Akkor úgy gondoltam, hogy egy JScript példa elég lesz. Közben rájöttem, hogy .Net környezetben ez kevés (a típusosság miatt jóval több dolgot meg kell adni). Ezért most itt egy C# metódusként megírt példa (a referenciák közé fel kell venni az ADO és a CDO COM Objektumokat):
public static CDO.Message LoadMsgFile(string FileName)
{
CDO.Message Msg = new CDO.MessageClass();
ADODB.Stream MsgStream = new ADODB.Stream();
MsgStream.Type = ADODB.StreamTypeEnum.adTypeBinary;
MsgStream.Open((object)System.Type.Missing,
ADODB.ConnectModeEnum.adModeUnknown,
ADODB.StreamOpenOptionsEnum.adOpenStreamUnspecified,
"","");
MsgStream.LoadFromFile(FileName);
Msg.DataSource.OpenObject(MsgStream,"_Stream");
return Msg;
}
|
By SUF on
2005. 09. 12. 7:41
Abba a problémába futottam a levlista program fejlesztgetése során, hogy hogyan dolgozzuk fel azokat a leveleket amik az SMTP szerver drop könyvtárába érkeznek, vagy bármilyen más MIME formátumú levelet. Ha ez a levél eml kiterjesztéssel rendelkezik és egyszerűen rákattintunk akkor jön az Outlook Express és megmutatja a levelet. Természetesen ha programból kell csinálnunk valamit vele, akkor ez nem lesz ilyen egyszerű. Például mi van akkor, ha szükségünk van egy From egy To vagy egy Subject mezőre? Esetleg a levél törzsét (HTML Body) szeretnénk letárolni egy adatbázisba?
Megtehetjük azt, hogy reguláris kifejezésekkel kiszedjük a fájlból amire szükségünk van. Megtehetjük, hogy írunk egy feldolgozó programot ami megfelelően szétszedi a levelet az igényeinknek megfelelően. Egyik megoldás sem egyszerű, ráadásul szükségtelen. A Microsoftnak van egy megfelelő objektum könyvtára erre. Ez a CDO (vagy CDOEX).
A feladatunk annyi, hogy a levelet betültsük egy CDO.Message objektumba. Ezzel csak egy probléma van. Ez az objektum nem kínál közvetlenül olyan lehetőséget, hogy fájlból betöltsük a tartalmát. Ezért azt tehetjük meg, hogy a fájlt megnyitjuk egy ADODB.Stream-ként és ezt adjuk meg adatforrásként a CDO.Message objektumnak. Ez JScriptben így fog kinézni:
function LoadMsgFile(FileName)
{
var adTypeBinary = 1;
var Msg;
var MsgStream;
Msg = new ActiveXObject("CDO.Message");
MsgStream = new ActiveXObject("ADODB.Stream");
MsgStream.Type = adTypeBinary;
MsgStream.Open();
MsgStream.LoadFromFile(FileName);
Msg.DataSource.OpenObject(MsgStream,"_Stream");
return Msg;
}
|
By SUF on
2005. 09. 08. 12:14
Amióta a technetklub levelezőlista a régi (gyanítom Exchange OWA tetejére fejlesztett) verziójából átkerült a Lyris-re azóta foglalkoztat, hogy érdemes lenne írni egy levlista motort.
A Lyris rossz (Nem szeretnék ennél csúnyábbat leírni, bár lenne kedvem. Mindenkinek a piszkos fantáziájára bízom).
A múltkori Geek Dineren feldobtam, mint a technetklubos közösség összekovácsolására használható eszközt, hogy mi lenne, ha a listán lévő emberkék közösen fejlesztenének egy levlista motort és a Microsoft mögé állna. Lehet, hogy én vettem le rosszul, de nem úgy néz ki, hogy ez meg fog történni.
Végeredményben oda jutottam, hogy nekem kéne ezt elkövetnem.
Folyamatosan azt érzem, hogy nagy falat ez nekem. Ugyanakkor bújkál bennem a kisördög, hogy hátha mégis képes vagyok rá. Egy nagy kupac dolog foglalkoztat a levelezés tájékán, amik mindenképp az érdekes kihívás kategóriájába tartoznak. Ezen dolgok egy jórésze egy esetleges levlista motorban is jól hasznosítható.
Belevágtam. Nem tudom mi sül ki belőle, meglátjuk.
Egyenlőre kiizzadtam magamból egy adatbázistervet, a fejemben kavarog, hogy miket kellene megvalósítani. Irogattam hozzá ezt-azt, de lehet, hogy mélyebben kellene tervezni. Meglátjuk.
Egyenlőre az eszközök amit használni akarok:
- MS SQL Server 2000
- JScript
- ASP ???
- MS SMTP Service
- Index Server ???
- CDO
Itt tartok most. Folytatás következik ... (remélem)
|
By SUF on
2005. 09. 08. 11:46
A PDAs külföldi bohóckodásaimhoz írtam, hogy kíváncsi vagyok a telefonszámlámra. Ma megérkezett az e-mail tömeg a szolgáltatótól. Félve adtam össze a saját részletezőmet.
Sok.
De ezt tudtam bár ennél többtől tartottam. 50eFt. Talán ezért még nem vernek meg a cégnél. 
|
By SUF on
2005. 08. 29. 12:27
Azt hiszem, most fognak többen a fejemre koppintani. Tudom ugyan magamtól is, hogy elég gyenge az angol nyeltudásom és ez az évek során még meg is kopott, de igazán most fogok szembesülni vele. Elindítottam a web oldalam angol verzióját. Elég hiányos, a cikkek nagy százaléka nincs lefordítva, de hátha olyat is érdekel amit csinálok aki nem beszél magyarul (tudom, hogy a magyar világnyelv, de akkor is ... ).
További újdonság az oldalon, hogy elkövettem egy kiegészítést a Windows Server 2003 önmagában butácska POP3 szolgáltatásához. Gondolom vannak néhányan akik nem akarták, vagy nem tudták megvenni az Exchange-et, talán ők hasznát veszik.
|
By SUF on
2005. 08. 29. 0:00
[04/03/2009] Ez a cikk jó régen készült (ahogy ez a dátumból is látszik) az eredeti weboldalam számára: http://www.gomori.hu. Miután ezt az oldal családi célokra fogom használni, az informatikai cikkeket elköltöztetem ide.
Megpróbáltam bevezetni a Microsoft Windows Server 2003 POP3 szolgáltatását, de észrevettem, hogy két fontos (legalábbis számomra fontos) szolgáltatás hiányzik belőle. Ezek az Autoforward és az Alias címek (annak a lehetősége, hogy egy levelesládához több e-mail címet rendeljünk). Miután szükségem volt ezekre a funkciókra a bevezetéshez, írtam egy script-et ami kiegészíti a POP3/SMTP szolgáltatást velük.
A fent vázolt funkcionalitást SMTP Event Sink-ként JScript-ben valósítottam meg.
A script Access adatbázist használ (Microsoft Jet motor) a szükséges adatok tárolására. Az adatbázis két táblával rendelkezik:
Alias tábla:
| Oszlop |
Adat |
| ID |
Automatikusan növekvő azonosító mező. Ez a megvalósítás nem használja. |
| Alias |
Az alias cím. |
| Mail |
Az eredeti cím. |
Forward tábla:
| Oszlop |
Adat |
| ID |
Automatikusan növekvő azonosító mező. Ez a megvalósítás nem használja. |
| Mail |
Az eredeti cím. |
| Forward |
Forward címek. Több cím is lehet benne |
| KeepOriginal |
Meghatározza, hogy a levelet kézbesíteni kell az eredeti levelesládába is vagy nem. |
Minden e-mail tipusú mezőnek SMTP:name@domain formátumban kell lennie. Ahol a több cím megengedett pontosvesszővel kell elválasztani őket.
A script forráskódjában a DBfile változó tartalmazza a használt adatbázisfájl teljes elérhetőségét. Az adott környezetnek megfelelően kell beállítani.
Regisztráció: A regisztrációs folyamat megfelel bármely más SMTP OnArrival Event Sink regisztrációjának. A pontos parancsok itt találhatóak:
cscript smtpreg.vbs /add 1 OnArrival
Pop3Helper CDO.SS_SMTPOnArrivalSink "mail from=*"
cscript smtpreg.vbs /setprop 1 OnArrival
Pop3Helper Sink ScriptName "c:\Scripts\SMTP\pop3.js"
Szerencsére ehhez a megoldáshoz nem szükséges második SMTP Virtual Server-t létrehozni és átküldeni rajta a leveleket mert az üzenet mindíg MIME formátumban van, tehát nincs MAPI/MIME konverzió.
A forráskód és az üres adatbázis innen tölthető le.
|
By SUF on
2005. 08. 27. 12:23
Feltettem egy kérdést a levlistán a minap. Viszonylag ritkán szoktam kérdezni, de most megtettem. Kiváncsi voltam, hogy az előttem álló problémát mások hogyan szokták megoldani.
A feladat a következő:
Van egy Exchange szerverem (ami mellesleg DC, meg fájl szerver is) ami kezd kifogyni a szabad helyből. Úgy döntöttem, hogy a bővítést nem plusz diskek berakásával, hanem a jelenlegiek cseréjével fogom megoldani. Ez néhány órás rendszerleállást okoz. Ez felveti azt a problémát, hogy mi legyen a közben beérkező levelekkel. Az is lehetőség lenne, hogy nem törődöm az egésszel, mert a levelezőrendszerek alapértelmezett időtúllépései miatt nagy valószínüséggel nem okozna problémát, de ennél biztosabb megoldást szeretnék két okból:
1. Ha esetleg mégsem jönne össze az időtúllépésen belül megoldani a dolgot, nem vet jó fényt rám, hogy a leveleket küldők felé késleletetésre vonatkozó üzenetek menjenek vissza, ráadásul ha valaki átállítgatta a saját SMTP szerveret időzítéseit, akkor nyugodtan lehet, hogy eldobja a leveleket.
2. Mi van akkor, ha az upgrade valamilyen okból nem sikerül, de az SMTP service mégis elindul és elkezd leveleket fogadni. Hogyan fogom ebben az esetben kibogarászni a közben bejött leveleket?
Feltettem azt a kérdést, hogy:
"Ki, hogyan oldaná meg azt a feladatot, hogy mondjuk van egy Exchange szerver amit karbantartási okokból néhány órára le kell állítani és nem szeretném, ha ez idő alatt a rendszerről visszapattannának a levelek. Magyarán az lenne a feladat, hogy valami átmenetileg átvegye a leveleket és tárolja addig amíg az Exchange újra nem él, majd beadagolja ezeket a leveleket."
Többféle választ kaptam a kérdésre:
1. Megpróbálták megmagyarázni, hogyan működik az MX rekord, az SMTP és a DNS. Ezekről van némi távoli körvonalas fogalmam, nem igazán erre vonatkozott a kérdés. Tuti, hogy rosszul fogalmaztam (szoktam. ).
2. Többen javasolták a szolgáltató által nyújtott másodlagos relay szolgáltatást. Ez technológiailag jó lenne, ugyanakkor pont most versenyeztettem a szolgáltatókat, mert a bérelt vonalért jelenleg fizetett összeg nem picit barokkos. Ebben a képlékeny helyzetben nem szeretnék semmit megrendelni a jelenlegi szolgáltatótól.
3. Álítsak be másodlagos SMTP szervet! Na igen, erre gondoltam. Ugyanakkor senki sem fejtette ki, hogy ezt hogyan tudom a legkissebb munkával megoldani. Magánbeszélgetésekben hallottam erre PostFixet, másik Exchange-et stb. Ezekkel az a baj, hogy messze vannak a legkissebb munkáról alkotott elképzeléseimtől. A PostFix azért mert nem értek hozza, az Exchange meg azért mert nem szeretnék atombombával lövöldözni a bolhára.
Ezek után gondoltam, hogy maradok a fejemben lévő eredeti megoldásnál. Ez abból állna, hogy fogok egy XP-t, felrakom rá az SMTP Service-t, írok egy Event Sink-et ami berakja a levél fejlécébe az SMTP boríték recipient mezőjét és egy scriptet ami felveszi a Drop könyvtárból a leveleket és az Event Sink által berakott fejléc mezőben lévő címekre elküldi a levelet (ezek a scriptek úgy is jól jönnének nekem később másra).
Neki is kezdtem a munkának amikor is az MSDN-en mászkálva (http://msdn.microsoft.com/en-us/library/ms875938(EXCHG.65).aspx) valamin megakadt a szemem:
"The address list corresponds to the set of RCPT TO SMTP protocol commands received for the message, or the X-receiver headers present at the beginning of the message if it was submitted to the local SMTP service pickup directory."
Nézzük csak meg. Mi van akkor, ha a bejövő levelet az SMTP szolgáltatással lepakoltatom a Drop könyvtárba? Kipróbáltam. Szépen megjelenik benne az X-receiver mező. Hopp, Event Sink kilőve. Nem kell mert az SMTP megcsinálja maga. Ha már itt tartunk, továbbmentem. Némi konfig után beraktam az így kapott levelet a Pickup könyvtárba. A levél elment és megkaptam a céges levelezőben. Hurrá!!! Ugy látszik sikerül megoldanom a legkisebb munkával a problémát, még programolni sem kellett, hozzá. Akkor most a procedúra (hátha egyszer jól jön másnak is):
1. XP telepítés (Na ez nem fog kelleni, mert van gép amit tudok rá használni)
2. SMTP Service telepítés (XP tűzfalon beengedni a 25-ös portot!!!)
3. SMTP Service-en beállítani a szóban forgó domain-t mint lokális domain-t.
4. DNS-ben átírni az MX-et
5. Megcsinálni a szerver átállást, leellenőrizni, hogy minden megy-e
6. Visszaírni (kivenni) az MX-et
7. Kivenni az SMTP Service-en a szóban forgó domain-t a lokális domain-ek listájából.
8. A Drop könyvtár tartalmát átmásolni a Pickup-ba.
Kész.
Ha minden jól megy a jövő hét végén meg is csinálom az upgrade-et. Remélem sikerül gördülékenyen lebonyolítani a dolgot. Valahogy nem szeretnék olyan cikket írni a jövő hétvége után amilyet JoeP-nek sikerült (http://emaildetektiv.hu/2005/07/14/a-lehetetlenre-egy-kicsit-varni-kell/). Abszolult együttéreztem vele annak idején amikor olvastam.
|
By SUF on
2005. 08. 25. 16:19
Frissítettem a web oldalamat. Megint kijavítottam egy hibát a jelszó lejárat értesítő scriptben. Így jár az ember, ha megír valamit amit saját maga nem használ. A visszajelzés szerint mostmár működik. Belepiszkáltam a Levelesláda méretértesítőbe is, itt mondjuk csak egy szépséghibát javítottam ki ami zavart, a működést nem befolyásolja.
Azt érzékelem, hogy a második SMTP Virtual Server létrehozásával kapcsolatos lépésről-lépésre leírásom vagy hibás, vagy hiányos (a nagyját egy már megszünt MS KB cikkből vettem) így kellene írnom helyette egy másikat. Ez ráadásul nem is használható minden esetben, mert az fix, hogy egy SBS-es ISÁs multihome környezetben nem fog működni (ráadásul az ISÁhoz nem is értek, hogy kitaláljam mit kéne beállítani rajta).
Közben készülget az oldal angol verziója is.
|
By SUF on
2005. 08. 23. 14:15
Tegnap végre kézhezkaptam az új alaplapot, ma be is üzemeltem, egyenlőre jónak látszik.
|
By SUF on
2005. 08. 21. 18:22
Elsősorban azért, hogy ne dolgozzak folyamatosan, nem vittem gépet magammal a nyaralásra, csak a már korábban emlegetett PDAt amit a hétköznapokban is használok mint telefont, meg mozgó outlookot. A felállásról annyit, hogy a saját CAm tanusítványán kívül semmi sincs a gyári dolgokon kívül telepítve rajta. Összelőttem az Exchange ActiveSync-el, és eddig nem is igényeltem egyéb eszközt rá (eddig általában volt notebook, tehát bármit meg lehetett csinálni).
Otthon a leveleimet úgy kapom meg, hogy az Exchange-re jönnek be a céges dolgok, az Outlookban az Exchange accountom mellé még felvettem a freemailt mint POP3/SMTP accountot (erre érkeznek a különböző levlistás cuccok). Mielőtt eljöttem nyaralni, bekapcsolva hagytam az Outlookot, hogy szedje le a freemailes leveleimet is (tudom, hogy ez ronda megoldás, de ez volt egyszerű). Így elértem, hogy a PDAn mind a céges, mind a freemailes leveleimet tudjam olvasni. A freemailes levelekre persze így nem tudok válaszolni, de ez nem is volt célom (gondoltam naívan, megleszek nélküle).
El is telt egy hét nyugiban, olvasgattam a leveleim és elégedett voltam. Ekkor beesett egy megkeresés az egyik a weboldalamon lévő cikkel kapcsolatban. Ugyan a blogban leírtam, hogy magamon és házon kívül vagyok, de csak válaszolnék, hátha a kolléga nem olvassa és még azt hihetné, hogy nem foglalkozom vele. Azt tudtam, hogy simán nem fog menni, így nekiálltam eme egyszerû feladat megoldásának:
Küldjünk levelet a freemailrõl PDAval!
1. Bejelentkeztem a csodás freemailes webes felületre, végigküzdöttem magam a reklám és frame hegyeken, majd egy 2x2 centis ablakban megírtam a levelet. Megnyomtam a Mehet feliratú gombot és ...
nem történt semmi. Többször, különböző nekifutásokkal próbálkoztam, de a levél nem ment el. Webes felület kilőve.
2. Feldeztem, hogy a freemailnek van WAPos felülete a http://wap.freemail.hu címen (PDAs persze nincs). PDAn csak egy infó oldalt kapok, mert a packet ie ugye nem wap böngésző. Hurrá, lőjünk WAP böngészőt Pocket PCre. A freemail előzékenyen fel is ajánlja a WinWAP nevű cuccot (http://www.winwap.com/). Felmegyek az oldalra, látom van Pocket PC 2003-ra készült kiadás, letöltöm a próba verziót, abból is az exe-t.
Lejön.
Elindítom.
Közli, hogy nem erre a platformra való.
Hurrá! 
Akkor leszedem a zip kiadást.
Lejön.
Megpróbálom kicsomagolni.
Nem megy, nincs unzip a PDAn.
Irány a gugli.
Találok Pocket PCs unzipet (ezyUnZIP nevezetűt).
Letöltöm.
Elindítom.
Közli, hogy nem erre a platformra való.
Feladom (legalábbis a wapos felületet).
3. Ugye az az alap gond ezzel az egész levélküldéssel, hogy nincs olyan SMTP szerverem ami átvenné a levelet, mert fogalmam sincs, hogy ki a szolgáltatóm ebben a pillanatban, bárki más pedig elhajtana, hogy nincs jogom relayre. Gondolkozzunk fordítva. Nem folyamatos levelezést akarok, hanem egyetlen levelet elküldeni. Ha SMTP szervernek megadom a címzett domainjéhez tartozó MX rekordban lévõ szervert akkor annak át kell vennie a levelem, hiszen innen nem relay, hanem inbond levél. A címzett freemailes. Nézzük meg, hogy mi az elsődleges MXe a freemailnek.
Nslookup.
Oppardon, ez PDA, nix nslookup.
Felmegyek a domain.hu -ra keresés, freemail.hu, DNS lista, hurrá, van MXem:
fmx.freemail.hu
Létrehozok a PDAn egy POP3/SMTP accountot, POP3 szervernek beírom a freemail.hu -t, SMTP szervernek az fmx.freemail.hu -t. Elküldöm a levelem és megkönnyebbülök. 
Már csak arra vagyok kíváncsi, hogy ez a kis kaland mibe került (roaming díj, GPRS, stb.).
|
By SUF on
2005. 08. 19. 22:18
Azért látszik, hogy ez még Beta (vagy lehet, hogy így marad?). Az elõbbi bejegyzést nem ette meg egyben, közölte, hogy túl hosszú. :-/
|
By SUF on
2005. 08. 19. 22:15
Tettem néhány felfedezést a használhatóságával (vagy használhatatlanságával kapcsolatban. Az egyik kellemes meglepetés a blogomhoz választott Msn Spaces (teljsen véletlenül nyúltam bele, pont ez jött szembe amikor rám jött a firkálhatnék). Most fedeztem fel ugyanis, hogy nagyon korrekt PDAs felületet ad, így most tudok ide írni.
|
By SUF on
2005. 08. 19. 22:12
Itt ülök a nyaralás vége felé a szállodai szobában és már nagyon unatkozom. Mennék haza (vasárnap hajnalban megyek is). Másfél hete a PDAmon (HP ipaq 6340) élek (web, e-mail), mert notebookot nem hoztam magammal.
|
In order to add comments, you must register on the site. Simply select the Register link in the top right portion of the screen and enter your contact information. Once you are logged-in, you will be able to add comments.
Already registered? Click here to login to the site.
|
|