postfix

[Tomasz Kłoczko]

On Mon, 1 Mar 1999, Bartek Rozkrut wrote:

> On Sun, Feb 28, 1999 at 07:39:00PM +0100, Grzegorz Stanislawski wrote:
> >  Nie rozumiem. Jaki mamy zysk czasowy w przypadku gdy mta musi otworzyc
> > /home z 9000 katalogow, wyszukac wlasciwego katalogu luser, otworzyc go i
> ?!?!?!!?!?!
> /home z 9000 katalogów ?
> To współczuje userom...
> Ja przy 400 userach wprowadzam dzielenie home'a na grupy - np. teachers,
> absolwenci itp.
> Nie wyobrażam sobie tak olbrzymiego /home ... 

Ja mam takie ilości wpisów na maszynie gdzie jest ponad 4 tyś kont ale to
jest solek ;) (po około 400-500)
Solek w tym punkcie nadal jest leprzy od Linuxa. :l

dla mnie wrzucanie poczty do katalogu uzytkownika przy takich ilościach
kont maiłoby tą zaletę, że łatwiej się operuje ich zasobami. Przy
oddawaniu komuś czyiś zasobów (przeniesienie konta) jest poprostu
prostrze. Przędkość pracy systemu jakoś mniej mnie przy tym obchodzi.
nawet jeżeli na główny serwerek wydziałowy wejdą ze dwie grupy studentów
na raz to rzadko obciązenie skacze powyżej 70%.

Tak czy inaczej żeby nie było wątpliwości nie jestem definitywnie za
mailbox i przeciwny spoolowi w jednym katalogu. Uważam, że o ile to
możleiwe to w sposób łatwy przestawienie z jednego modelu na drugi powinno
być niemal automatycznie osiągallne. Linuxem zajmue się już całkiem spora
iliość ludzi. Spora ilość z tych co bedą używać PLD będzie miała nawyki
dość mocno zakorzenione w przeszłości. Nie można w takiej sytuacji zmuszać
kogoś do takiego czy ionnego zachowania jeżeli nawet w tym co możemy tu
uznać za nieco uwstecznione ten ktoś daje sobie dobrze radę będąc do niego
poprostu przyzwyczajonym i to po mimo może nawet obiektywnych
przeciwskazań do tego żeby stosować inny model pracy. Porostu trzeba
założyć, że tworzymy pewną platformę w której mamy optymalne warunki
paracy ale w razie czego można z tym wszystkim także pracować zupełnie
inaczej (np. w kwesti spooli pocztowych).

Dobra gadamy .. gadamy i nic z tego się nie wykluwa. Trza coś zrobić by
takie przejścia między modelami były możliwe i żeby nie kłóciły się z lege
artis administrowania. W przypadku sendmaila widzę to tak, że możnaby
przyjac, że w sendmailu PLD w zasadzie nie grzebie się w sendmail.cf i
wyłącznie operuję się na sendmail.{cf,cw}. Możnaby to nawet IMHO posunąć
do tego żeby za pomocą m4 przy starcie generować z .mc konfigurację
sendmaila, który zaraz zostanie wystartowany. Takie założenie umożliwiłoby
łatwe przetwarzanie konfiguracji sendmaila na konfigurację innego MTA np
postfixa.

Tak czy inaczej pora już skończyć z przekonywaniem się nawzajem bo to nie
ma za bardzo sensu, a pora zacząć opracowywać konkretne rozwizania.

Jeszcze co do wogóle skryptów w init.d to mam jedną taką porządkującą
uwagę. Może przywołam tu pewne zdarzenie jakie miało miejsce kilkadziesiąt
dni temu kiedy maciek Paliwoda opracowywał speca do inn (nadal jest IMHO
jeszcze nie skończona ta praca). Główne zalecenie jakie swormułowałem
Maćkowi przy opracowywaniu inn było taki, że inn powinien być
konfigurowany z prefixem /usr, a nie /usr/lib/news. Maciek miał tu jededno
"ale", że dożo ludzi jest przyzwyczajonych do używania skryptów które
wybierają ręcznie z /usr/lib/news/bin. Na co ja mu zasugerowałem żeby
spróbował sformułować listę typowych operacji jakie wykonuje sie w
trakcie administrowania inn, np. czyszczenie spoola i podpiął to pod
skrypt w /etc/rc.d/init.d/inn po to żeby znacznie odmitologizować i
uprościć zarządzanie inn, a osoby przyzwyczajone do klepania
/usr/lib/news/bin/<cośtam> w nowym podejjściu nie bądą musiału pisać
pełnej ścieżki mogąc jednocześnie wogóle nie korzystać funkcjonalności
jaką zawrzemy w /etc/rc.d/init.d/inn.

"Abo owo" (do sendmaila i generowania konfiguracji) .. możnaby w tym
sensie rozszerzyć funkcjonalność /etc/rc.d/init.d/sendmail żeby przez
wywołanie "/etc/rc.d/init.d/sendmail genconfig" generować konfigurację o
ile ta np. nie będzie gemnerowana przy "/etc/rc.d/init.d/sendmail start" z
pliku .mc (co chyba byłoby bardziej rozsądne). Także o ile powstawałyby
np. narzędzia interakcyjne do konfigurowania poszczególnych serwisów
(choćby oparte o dialog) możnaby to analogocznie podpinać pod
"/etc/rc.d/init.d/sendmail config". To tak apropo propozycji pewnych
rozwiązań ..

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*