Day: January 6, 2006

Eső

Ilyen esős napokon rendszerint bedugul a város – még azok is kocsiba ülnek, akik korábban nem szoktak. Ez remek – gondolhatnám – hiszen akkor kevesebben lesznek a tömegközlekedesben. De nem. A buszokon is sokkal nagyobb a tömeg.
Honnan jön ez a sok ember? Akárhogy is töröm a fejem, csak arra jutok, hogy ezek a gyalogjárók lehetnek. Mely egyben jó hír is – mégsem annyira punnyadtak a városlakók, mint ahogyan elképzeltem.

[Update]
Gyönyörű levezetés, de valahogy éreztem, hogy nem teljesen stimmel. Eleve nem lehetek biztos a dolgomban, hiszen egyszerre, egy időpontban nem vagyok tömegkozlekedő és autós is.
Oké, emlékszem, hogy amikor még én is autóval jártam, tényleg így volt. Az is tény, hogy mostanában a buszokon tényleg így van. De ma például nem ez történt – igaz, későbbi járatokkal mentem. Tehát összehasonlításkor számítana az időpont is. Aztán az sem biztos, hogy ilyenkor több az autó – könnyen lehet, hogy esős időben a gyakorlatlan sofőrök lassítják le a közlekedést – és ezt érezzük több autónak.
Szóval szép-szép ez a levezetés, csak éppen a premisszák véreznek ezer sebből.
Szócséplés.

A GC sem mindenható?

Őszintén szólva, még mindig tátva van a szám. Ettől a cikktől maradt úgy… pontosabban egy új, a GC-kre vonatkozó információtól.
A cikk egyébként több okból is nagyon jó. Meg lehet pl. tanulni belőle, hogyan tudom gyorsan megállapítani, mely GC-ket lát az Exchange szerver. (Pontosabban a DSACCESS szolgáltatása, mely a GC-XCH kapcsolatért felel.) Élvezetes a gondolatmenet, ahogy Jasper felgöngyölte a problémát. És megtudhatjuk, hogy megint a Public Folderek a bűnösek. És hogy a GC-k sem tudnak mindent.
Számomra ez utóbbi volt az igazán megdöbbentő:

It turns out that Exchange does not always use the local GCs. For certain specific security related user attributes like tokenGroups and tokengroupsGlobalandUniversal (used to determine what security groups a user is a member of and therefore what permissions s/he has to secure resources such as public folders). Exchange MUST query a DC that is authoritative for the user’s home domain, which will likely be an out-of-site DC—in this case it happened to be a DC in Australia. This behavior was introduced around the Exchange 2000 SP2 time frame to address an issue where users from remote domains (sibling or parent) were denied access to public folders even when the security groups they were in should have allowed them access. Pre-SP2 we had made the false assumption (in the product) that a local GC can service ALL queries that Exchange issues. A local GC can (and should) service MOST queries in a well designed multi-site AD environment.

Eltekintve attól, hogy erősen hiányzik egy ige a második mondatból, kihámozható, hogy Jasper szerint a GC adatbázisok nem tartalmazzák azokat az információkat, hogy a felhasználók mely biztonsági csoportoknak a tagjai. Ez alapjaiban rendítette meg az elképzelésemet a GC-k működéséről. De tényleg. Hiszen pont azért találták ki, hogy gyorsan, mindenféle DC abuzálás nélkül el lehessen dönteni, hogy Géza hozzáfér-e egy erőforráshoz, vagy sem?
A többi már csak hab a tortán; hogy Exchange SP2 előtt ilyenkor meghalt a PF elérés, SP2 után viszont megpróbálja a világ másik végén lévő helyi GC-t használni. Aztán van amikor ezzel több kárt okoz, mint hasznot.