|
ru.unix
- RU.UNIX ----------------------------------------------------------------------
From : Pavel Marenyuk 2:5080/1003 21 Feb 2006 23:12:50
To : Valentin Nechayev
Subject : Re:postfix-говно
--------------------------------------------------------------------------------
Valentin Nechayev <netch@segfault.kiev.ua> wrote:
VN>
VN>>> Вот так и с постфиксом. Одно дело - поставить нечто что требует
VN>>> глубокого разбирательства ибо конфигов нет вообще (была в 70-х такая
VN>>> манера - юниксы поставлялись вообще без /etc, админы их себе писали
VN>>> с нуля). Другое дело - когда конфигурация типа есть, и она по
VN>>> определению обещана работоспособной для базового случая и
VN>>> безопасной, но в неё заложен хитрый такой подводный кирпич, который
VN>>> всплывёт в самый неподходящий момент.
VN>
PM>> Hу так, работоспособная она и, какраз, для базового случая.
VN>
VN> Так дело в том что таких базовых случаев минимум два.
VN> Первый - гуляю сам по себе, второй - ещё и локалку знаю.
VN> Считать базовым только второй - диверсия даже для локалки. Hапример,
VN> я ставлю себе десктопный... мнэээ... альт (или кто там постфикс
VN> тащит). Он мне должен периодически письма писать, например, с
VN> отчётом apt-get update, а с другой стороны - мои ящики держать.
VN> Почему я вдруг по умолчанию оказывается релею всё от соседей,
VN> которые с трудом отличают мышь от клавиатуры и у которых вирусы друг
VN> друга уже заражают?
VN>
Утверждается что альт даже выкрутил mynetworks_style в host.
Суся mynetworks_style не трогает, но ставит две чеки :
postconf -d| grep mynetworks
mynetworks = 127.0.0.0/8 10.2.0.0/16
mynetworks_style = subnet
postconf | grep mynetworks
mynetworks = 127.0.0.0/8 [::1]/128
mynetworks_style = subnet
cat /etc/postfix/master.cf | grep smtp
#smtp inet n - n - - smtpd
#submission inet n - n - - smtpd
VN> Вот и получается, что Венема (или кто там эту настройку ставил в
VN> дефолт) просто не подумал, и не подумал не в более защищённую
VN> сторону, а наоборот. За что и пинаем.
VN>
PM>> Можно вставить чеку имени "remove_or_comment_it" - но ето сродни надписи
PM>> "не предназначено для сушения кошек" на микроволновке,- помешать засунуть
PM>> кошку - не в состоянии, зато на претензии "микроволновка-говно" - есть
PM>> отмазка...
VN>
VN> Эта чека хоть даёт причину слазить в конфиг. Метод слишком грубый,
VN> конечно, но действенный. А иначе на каком основании я буду отличать
VN> MTA от десятков других программ (включая сетевые), которые тоже
VN> могут требовать напильника?
VN>
VN> Самый правильный, конечно, вариант - спросить при установке
VN> средствами скрипта пакета - "вы тут совсем один живёте или в семье?"
VN> Вот если бы так было сделано - ни я ни AK слова бы поперёк не
VN> сказали.
VN>
Так делают дистрибутивы.
А задавание вопросов на этапе make foo может быть неадекватно расценено.
VN>>> Hу нельзя рассчитывать что админ будет просматривать полностью всю
VN>>> документацию и учитывать все тараканы каждой подсистемы. Хватит уже,
VN>>> времена когда деревья^W компьютеры были большими и занимали целый
VN>>> зал - кончились.
PM>> И не нужно.
PM>> Hо вот если ставится "типа почтовая система" или "типа веб сервер"
PM>> просмотреть default config и поправить, хоть руками, хоть гуевой
PM>> конфигурялкой - крайне не помешало бы.
VN>
VN> Ещё раз: на каком основании я буду выделять почтовую систему из
VN> остальных? У меня может поставлены ещё sshd, samba, portmap+NFS,
VN> ftpd, апач с кастомными модулями, десяток сервисов RPC поверх
VN> портмапа и ещё полсотни локальных хаков поверх inetd. А почта нужна
VN> для того чтобы суточные отчёты слать. Hу почему я ещё должен
VN> разбираться в нетривиальной программе и делать то, что за меня
VN> должен был сделать автор дистрибутива или даже самого MTA?
VN>
Авторы дистрибутивов(некоторых) - сделаи.
Hо в ситуации АК, локальный админ, выбрал путь сборки.
--
Всем - всего
--- ifmail v.2.15dev5
* Origin: (http://news.cca.usart.ru/) USURT's FidoNET<-> (2:5080/1003@fidonet)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
