jak nejlepe - users,login.conf

[Jiri]

Hello Dan,

Wednesday, May 26, 2004, 4:05:41 PM, you 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...

momentalne to zkousim na obstaroznim domacim pc, a hodlam nektere veci
nahazet do jailu atd. nekteri useri by rovnez meli mit jen scponly -
zadny shell.

tudiz neocekavam ze si budou useri neco moc kompilovat v homu ci delat
nejake divocarny...

jaky by tedy mohly byt hodnoty? pozdeji samozrejme to hodlam
provozovat na silnejsim stroji, ktery by se dal casem dobre rozsirovat
(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?

:cputime=unlimited:\
        :datasize=unlimited:\
        :stacksize=unlimited:\
        :memorylocked=unlimited:\
        :memoryuse=unlimited:\
        :filesize=:\
        :coredumpsize=unlimited:\
        :openfiles=512:\
        :maxproc-cur=30:\
        :maxproc-max=60:\
        :sbsize=unlimited:\
        :vmemoryuse=unlimited:\
        :priority=0:\

>> OK, takze jestlize nyni vytvorim noveho uzivatele, tak se mu
>> nakopiruji do homu soubory z /usr/share/skel. Ty vsak muhou byt v
>> rozporu s nastavenim pro tridu v /etc/login.conf.
>> 
>> Jaky by byl nejlepsi postup? Pridat dotdir = "no" do
>> /etc/adduser.conf?
>> Zeditovat /usr/share/skel? Nebo mit pro kazdou tridu vlastni dot
>> soubory? Napr. /usr/share/skel/users, /usr/share/skel/goodusers ?? :)

DL> 	Ja pouzivam to prvni. Rozkopirovavani konfigurace pripravene spravcem
DL> "jako uzivatelske" povazuju za koncepcni chybu, ktera pozdeji muze
DL> jedine zkomplikovat spravu pocitace.

jo, jsem cetl ze takovy soubory by mely byt v /usr/local/share/skel
nebo obdobne podle ruznych verzi, aby to nebranilo jednoduchemu
upgradu...

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?

>> 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?

diky za tipy a rady. zatim

-- 
Best regards,
 Jiri                            mailto:jiri.b at sendmail.cz