Další ze skvělých přednášek od Susan Bulloch. Člověk by si řekl, že už to všechno ví a přesto se pořád dozvídá novinky a novinky. A jakkoliv jsou drobné tak jsou skvělé.
Takže AdminP byl uveden snad ve verzi 4.5 a ještě ve verzi 5 šel vypnout. Od verze 6 už to nejde, protože je zodpovědný skoro za všechno a skoro nic by tedy nefungovalo. Přesouvá databáze, maže je, přejmenovává uživatele, ruší je, sleduje verze serverů a klientů pro pozdější snadný upgrade. Umožňuje (od verze 6) uživatelský přístup k mailu pouze na úrovni Editor a ve spojení s CA zajišťuje registraci uživatelů přes web.
Co je na něm krásné je, že když se nechá tak se sám konfiguruje tak jak je to nejlepší. Jeho replika ID je závislá na adresní knize a nesmí se změnit – všechno pak přestane postupně fungovat. Navíc, pokud se v admin4.nsf (admin4, protože to bylo uvedeno ve verzi 4 a někomu připadalo jako skvělý nápad tam tu verzi uvést) něco pokazí, tak ho lze smazat a po startu serveru se znovu stáhne z administračního serveru. Některé procesy mohou trvat týden, některé i déle – k dispozici je popis jak přesně který proces funguje, takže pokud nemůžete spát tak je to skvělé čtení. Všechno, co se dotkne dokumentů v adresní knize nebo souvisí s mazáním databáze, musí být schváleno administrátorem.
Standardně běží adminP každou hodinu a kontroluje nové úkoly. Toto jde změnit, u velkých nastavení se doporučuje snížit to až na 15 minut a mělo by to trochu vázat na interval replikace admin4.nsf a names.nsf v rámci domény. Požadavky, které mají být provedeny okamžitě se udělají do minuty od zapsání do databáze a jsou označeny speciální ikonou. A pak jsou takzvané „batched“ požadavky, které se sbírají mezi jednotlivými běhy adminP procesu a udělají se všechny najednou – změna ACL, změna jmenných polí. Kvůli nim by měl být zase interval mezi jednotlivými běhy co nejdelší, aby se sešlo co nejvíc požadavků, které se najednou udělají výrazně rychleji než každý zvlášť. A aktuální je takových požadavků 18 různých druhů. A pak jsou požadavky, které probíhají jednou denně – mezi ně patří přejmenování uživatele v seznamu nepřečtených dokumentů. Takže pokud přejmenujete uživatele a on má najednou všechny dokumenty nepřečtené, tak by mělo stačit počkat do druhého dne.
Co se týká přístupu do admin4.nsf tak ve verzi 5 musel být na úrovni autor, od verze 6 už může být pro uživatele bez přístupu, pro administrátory alespoň na úrovni autor. A samozřejmě je důležitá správná replikace, protože jinak může růst nekontrolovatelně. S tím souvisí i retention period, která je standardně 7 dní, hezké nastavení je 10 dní, protože jsou v tom dva víkendy a server se může o něco lépe kontrolovat. Víc než 21 dní už je zbytečné a může být problemtické ve velké organizaci. U jednoho zákazníka tak prý bylo v databázi 750 000 dokumentů, protože tam bylo hodně serverů a takové přejmenování uživatele vygenerovalo hodně požadavků, na které servery odpovídaly, že je neprovedou, protože u nich uživatel nic nemá. A k tomu slouží nové skvělá volba v server dokumentu, která říká, že pokud server nic neudělal tak nemá generovat dokument v admin4.nsf. Volba se jmenuje Store Admin Process log entries when status of no change is recorded.
Skvělá volba pro urychlení procházení databází při změně jména uživatele – stačí do každé databáze dát pohled ($Adminp) ve kterém budou vybrané dokumenty, které mají čtenářské/autorské políčko a které mají být změněny. AdminP potom projde jenom tento pohled místo celé databáze. To si přímo říká o zavedení do všech databází. A s tím souvisí i příkaz Tell AdminP Show Databases, který do logu vypíše všechny databáze s informací o administračním serveru.
Nikdy nepoužívejte naproti tomu příkaz Tell AdminP Process All, protože zprocesuje úplně všechny nevyřízené požadavky a může totálně zahltit server. A taky nikdy nepřipojujte server, který byl odpojen od domény dlouhou dobu – vrátil by všechny staré požadavky a mohl by to celé hezky zbláznit (což už se nám u jednoho klienta stalo). Opatrně bychom také měli zacházet s volbou pro změnu jmen ve všech jmenných polí, která se dá nastavit v ACL každé databáze. Při mazání člověka totiž může dojít k tomu, že se smaže i poslední záznam z čtenářského pole a dokument se v tu chvíli zpřístupní všem. A pokud to člověk aktivně zapne na poštovní databázi tak zjistí, že mu z odeslaných emailů mizí informace o tom, komu všemu to poslal. Ale aby to nebylo tak špatné, tak prý existuje požadavek od zákazníků, aby se tato volba nastavovala zvlášť pro přejmenování člověk a zvlášť pro mazání – u přejmenování bych byl proto, aby to probíhalo, u mazání jsem proti. Tak snad to udělají co nejdříve.
A zajímavost nakonec – při přejmenování lidí v Evropě se doporučuje prodloužit interval, po který se bude udržovat staré jméno (standardně je to 21 dní). Když jsem se zeptal proč, tak jsem se dozvěděl, že jenom v Evropě si lidé berou třeba tři týdny dovolené, že v Americe už by je dávno vyhodili. A to je důvod proč pijí tolik kávy ve velkých hrncích. A ještě jedna fajn informace – LN prý nemají rády krátké jména serverů v dokumentu pracovišť, takže se doporučuje tam mít plné jméno serveru. Problémy to může činit jak administračnímu procesu tak Dynamic Client Configuration procesu. A pokud člověk používá CA, tak certifikáty zaregistrovaných lidí jsou uloženy v admin4.nsf místo v certlog.nsf, takže i díky tomu ta databáze trochu roste.