jak nejlepe - users,login.conf

[Dan Lukes]

Jiri wrote:
> DL> 	Neexistuji nejake obecne optimalni hodnity. Vzdy lze o optimu hovorit
> DL> jen ve vztahu ke konkretni situaci - tedy tomu, co ti uzivatele (bezne)
> DL> delaji, jaky je k dispozici hardware, co je vlastne cilem implementace
> DL> takovych omezeni ...
> 
> ok :) no uzivatele by meli, podle typu, vyuzivat nekolik sluzeb:
> - ssh, mail, lynx, irc, silc a dalsi bezne apps; zadne X
> tudiz by na serveru mel bezet sshd, apache, databaze, postfix, clamavd,
> spamassasin, vlastni silc-server, squid...

	Ani takhle neni jednoduche dat "obecnou" odpoved. Seznam aplikaci 
nestaci. Krome toho, i v tech pripadech, kdy clovek vi vsechno co 
potrebuje je jednodussi nektere veci vyzkouset nez spocitat.

	Nejdriv uvedu, ze vubec netusim co je silc a nemam nejmensi predstavu o 
pametovych a vykonovych narocich irc. Takze tyhle dva programy se v 
lasledujicich radach neobjevi v prikladech.

	A zkusim to takhle -
pokud uzivatele nebudou pouzivat server na skladovani dat, bude 
nejvetsim souborem uzivatele patrne /var/mail/$LOGNAME

limit na velikost souboru je tedy potreba zvolit s ohledem na to, kolik 
se predpoklada, ze by tam mohli mit dopisu a jak dalece jste na stiru s 
mistem na disku

Za nejvetsiho zrouta casu procesoru lze patrne oznacit ssh a to pokud 
forwarduje spojeni nebo prenasi soubor(y). Otazka je, jak dalece ma 
vubec smysl cas procesoru limitovat. Soubeh s "dulezitejsimi" aplikacemi 
spise lepe resi priority nez limit.

	Pokud uzivatele neladi (a vy take ne), neni duvod ponechavat nenulovou 
hodnotu coredumpsize - obzvlaste pokud mate problemy s mistem na disku

	Pametove limity zase souviseji nejen s potrebami jednotlivych apliaci 
(ktere neznam), ale take s tim, kolik uzivatelu bude stroj pouzivat 
soucasne. Neni ale prilsi dobre je volit prilis nizke - nektere aplikace 
proste narazove alokuji vetsi mnozstvi pameti na kratkou dobu, coz, 
treba, pri pohledu na "top" nebo "ps" spise neuvidite.

	Maximalni pocty procesu i otevrenych deskriptoru mohou byt pro 
uzivatele relativne male - nesmi se ale zapomenout na pripadnou 
existenci ruznych automaticky spoustenych scriptu bezicich v kontextu 
uzivatele (cron, presmerovani dopisu do scriptu a pod.)

> jaky by tedy mohly byt hodnoty? pozdeji samozrejme to hodlam

	Nevim, jestli vam nekdo dokaze dat nejaka konrketni cisla. Pokud ano, 
ja to nebudu. Pro rozhodnuti o kazdem z nich je treba znat velmi sirokou 
skalu informaci tykajici se obvykleho chovani uzivatelu i detailni 
pozadavky pouzivanych programu. To neni neco, co se da resit "na dalku". 
I na blizko by to znamemalo - nastrelit, pozorovat, doladit (a dokola).

> (jaky by mohl byt minimalni stroj? pro cca ze zacatku 100 useru,
> nekolik desitek normalnich webhostingu, 2 mailservery? to vse porudzu
> rozhazeno do cca 3 jailu?

	To takhle opravdu nejde - nezname pocty soucasne pracujicich uzivatelu, 
odhadovane objemy dat a to jak tech skladovanych tak prenasenych, 
konfiguraci HTTP serveru (je zasadni rozdil v narocich na hardware kdyz 
se povoli scripty, povoli PHP a pod., je zasadni rozdil v narocich na 
procesor pokud se on-line pakuje, pouziva mod_rewrite a pod.) ...

	Ja vam to reknu jinak. Podle me, stroj v hodnote 20000 bez DPH vam 
patrne (uz) postaci, v cene 30000 pak zcela urcite.

	Jen ve velmi vyjimecnych pripadech a pro specialni aplikace jsem 
potreboval drazsi stroj ...

> DL> 	Kdyz chci, aby neco platilo pro vsechny uzivatele, nastavim to v 
> DL> prislusnych centralnich konfiguracnich souborech. Pokud to nekomu 
> DL> nevyhovuje, vetsinu nastaveni lze v uzivatelskych souborech prenastavit
> DL> - tak at to uzivatel, ma-li takovy individualni pozadavek, udela. Od
> DL> toho ty uzivatelske konfiguraky jsou. Ale nejsou, IMHO, od toho, aby do
> DL> nich jakkoli zasahoval centralni spravce. Podotykam, ze "zasahovat"
> DL> zahrnuje v mem chapani i "vytvorit s nejakym obsahem".
> 
> jinak, asi by ale bylo jednodussi ty soubory tam userum
> nakopirovat nez jim nejak vysvetlovat, kde si je maji zkopirovat a
> pripadne upravit podle sebe ne?

	Proc bych jim neco vysvetloval "predem" ?

	Jestli chteji nejake chovani upravit, tak to stejne musi umet - takze 
tomu pripadnemu vysvetlovani se nevyhnete. Poradit jim, kde sezenou 
nejaky vzor je pak uz jen maly detail.

	Jestli si myslite, ze by mohla byt nejaka vyrazna pomoc v tomhle, tak 
do jim tam pri vytvareni kopirujte neaktivni examply. Rozhodne si 
nemyslim, ze je k necemu dobre (naopak jsem presvedcen o skodlivosti) 
aby spravce kopiroval uzivatelum do jejich adresaru aktivni uzivatelske 
konfigurace. Tak nejak mi ta veta proste pripada vnitrne rozporna a cela 
akce nesmyslna.

>>>Dalsi dotaz je, jak to mate zarizene, jestlize spravuje server vice
>>>lidi, ale nechcete dat kazdemu heslo k rootovi? Plz popiste nejaky
>>>letmy navod.
> 
> 
> DL> 	Co v tomto kontextu presne znamena slovo "spravovat" ?
> 
> DL> 	Mimochodem, je vaznym prohreskem proti zakladnim pravidlum bezpecnosti,
> DL> aby jakekoliv "tajemstvi" sdilelo vic osob, nez je bezpodminecne nutne.
> DL> Jelikoz na UNIXech neni obvykle duvodu, aby k jednomu uzivatelskemu uctu
> DL> znalo heslo vic uzivatelu nez ten jeden, je system na kterem k tomu
> DL> dochazi z bezpecnostniho hlediska zavadny. To plati (obzvlast vzhledem k
> DL> dulezitosti toho uctu) i pro ucet "root".
> 
> jsem primo prave nemyslel aby nekdo znal heslo roota! ba prave jsem
> myslel, ze jako napr jeden spravce nema neustaly cas resp kdyby byl
> druhy pomocny spravce/i tak jak to osetrit aby mohl pripadne
> udelat/pripravit zmeny? napr. co kdyz sverim spravu nejake casti
> serveru nekomu jinemu a ja se budu venovat napr ladeni jine? to nejak
> nejde promyslel, osefovat? vim ze je to dost reseni nesmyslu, ale
> zajimalo by me to... urcite vsude nespravuje server jen jeden clovek,
> co ty hostingy, kde je 24/7 dohled atd.? jak to tam chodi?

	Neodpovedel jste mi na otazku - ptal jsem se, co pro ucely tohoto 
dotazu znamena "spravovat". Mohu to klidne zopakovat malinko jinak - co 
pro vas znamena pojem "spravovat cast serveru" ?

	Asi nerozumim resenemu problemu. Takze vase otazka "jak zajistit aby 
pomocny spravce mohl (take) delat potrebne zmeny" ma bud' trivialni 
odpoved - proste mu zalozim (take) ucet s UID 0, nebo jsem nepochopil 
otazku. Samozrejme, ze je uplne bezne, ze jeden stroj ma vic spravcu - a 
to nemluve o dalsim spravcovskem uctu, ktery sice neni bezne pouzivany, 
ale jeho heslo lezi v trezoru v obalce pro pripad havarie nebo pro jine 
zvlastni potreby majitele firmy.

	Jestli nejakemu cloveku chci dat rootovska prava aby se mi o server 
staral, tak mi uz nepripada podstatne, jestli je ma fakticky jen dve 
hodiny denne, kdyz mi pomaha, nebo jestli je ma celych 24 hodin. Jakmile 
ma prava roota jen na minutu, stejne musi byt duveryhodny - a to se asi 
za par minut patrne nezmeni. Co se tyce toho "svereni spravy casti" 
zatimco "ja se zabyvam ladenim" - OS neresi jak vy si mezi sebou 
rozdelujete praci ani kdo co kdy dela. To se dohodnete pri rannim kafi 
spolu, pak si kazdy sednete za svoji klavesnici, kazdy se prihlasite na 
svuj ucet s UID 0 a delate to, na cem jste se dohodli a jak jste se 
dohodli. Predpokladam-li, ze kazdy spravce je dostatecne duveryhodny (a 
jiny mu ucet s UID 0 mit nemel) pak neni duvod, aby system nejak 
zjistoval aa/nebo zajistoval dodrzovani dohod, ktere jste si vy mezi 
sebou udelali. Ale mozna jen opravdu nerozumim tomu co resite ...

						Dan



-- 
Dan Lukes,  SISAL, MFF UK  tel: +420 2 21914205, fax: +420 2 21914206
AKA: dan at obluda.cz, dan at freebsd.cz, dan at kolej.mff.cuni.cz, dan at fio.cz