Fri, Oct 16, 2015 at 02:35:11, eugen wrote about "Re: [freebsd] sendmail +
roundcube":
> >> Можно подумать, sendmail негибок в конфигурировании или много жрет :-)
> > sendmail очень неудобен и сложен в настройке, особенно если требуется
> > гибкость,
> Неправда. Так может говорить только тот, кто не читал документацию
> на используемый софт, но с exim или postfix ситуация такая же:
> неудобно тому, кто доку не читает,
Евгений, я надеюсь, мой авторитет по sendmail (на основании K+1 года
его использования в продакшене и десятков патчей на разные темы) ты
опровергать не будешь? Так вот - я категорически подтверждаю слова
cirtin@: sendmail неудобен и сложен - по крайней мере для всего, что
выходит за рамки простой стратегии "накидать опций по ману в
${hostname}.mc и вызвать make", и эта сложность далеко выходит за
пределы того, что определяется "естественными" факторами сложности
тематики. По пунктам:
1. Основным средством конфигурации является "язык переписывания" на
основе идей REFAL. Это само по себе не было бы настолько тяжёлой
проблемой, если бы этот язык не пытались впихнуть вообще всюду,
включая места, где такое не нужно или неудобно.
В частности, тот же язык используется после уже давно состоявшейся
канонизации форм адресов для проверки релеинга. Я понимаю, что авторам
было лениво вводить ещё сущностей, и они тупо отдали тему на откуп
сообществу - мол, напишите нам реализацию, а мы её включим.
2. Но даже для работы с адресами этот код, за редкими исключениями,
не нужен. Да, есть всякие чрезмерно грамматичные адреса RFC822 (луч
пламенного привета IETF), но практически формата localpart@domain
хватает для 99.9999% случаев. На переходники с uucp/etc. можно
поставить и специальную обработку. При старте Exim, Philip Hazel
намеренно отрёкся от этого всего, и был прав - "в интернете" такое не
нужно.
Ещё хороший альтернативный подход показывает zmailer (кто-то ещё
помнит такое? Один киевский провайдер применял его лет 15 аж до своего
поглощения).
3. Код чудовищно архаичен и не подвергался редизайну верхнего уровня
и/или рефакторингу как минимум последние 30 лет. Для софта это просто
безумный срок.
Кто будет возражать - прошу вначале прочитать и понять логику таких
замечательных функций, как getrequests(), sendall(), dropenvelope(),
описать её словами. Продолжить содержимым файла queue.c, разобрать
тёмные моменты логики.
При изучении конкурентов не потребуется делать аналогичный выворот
мозга.
4. Код в текущем состоянии фатально непригоден для автоматизированного
тестирования. Я понимаю, что многие апологеты и классические авторы
open source, воспитанные в лучшем случае на идеях середины 60-х годов
и, может, немного слышавшие про ценность структурного
программирования, никогда про него не слышали или не понимают
ценности, и что это требует усилий больше, чем "just for fun"; но
почему-то:) у конкурентов это обеспечено лучше.
Присутствующие тесты покрывают только часть вспомогательных библиотек
и то в лучшем случае 1/10 от нужного.
Для сравнения, postfix написан предельно модульно (хоть и некоторые
идеи Венемы требуют бутылки водки для вкуривания в них) и при этом всё
равно в разы легче sendmail. Exim в основе цельно написанный, но он
всё равно проще в подходах.
5. Настройка по умолчанию несопровождаема кроме установки вида
"получать daily run output в локальный ящик". Начать с дефолта
LogLevel=9, который не пишет завершения заданий (и от этого нельзя
вести анализ доставки по логу). Далее, логика управления нагрузкой по
RefuseLA и QueueLA придумана для каких-то других систем, но не
современных юниксов (возможно, она для старого SunOS?) В наших
условиях (в первую очередь FreeBSD) она выливалась в самозаклин под
большой очередью, когда собственно чтение очереди уже даёт нагрузку
заметно выше уровня QueueLA. Там, где большие потоки, приходилось
ставить два демона - принимающий без ограничения по форкам, но с
QueueLA=1, и разгребающий с QueueLA=дофига, но жёстким ограничением по
количеству потомков и ненулевым MaxQueueAge - и только в таком виде
удавалось получить устойчивую конфигурацию. Об этом я писал где только
можно и жаловался авторам, но ответа не было - в лучшем случае "вы же
придумали, как это правильно делать, вот и радуйтесь себе в тряпочку".
Это только малая часть того, что стоит ругать - но не хочу сейчас
тратить много времени.
Причины этого всего мне видятся в следующем факторе: sendmail, по
сути, продукт коммерческий, и был таким изначально, а то, что мы
получаем в доступном виде это урезанная версия "для ширнармасс". Любая
непонятка, с точки зрения авторов, должна вылиться в приход к ним в
гости с пачкой денег на тему "сделайте мне хорошо", и тогда они
вытащат все свои наработки от правильного стартового сетапа до всех
форм секретных патчей типа "100500 параметров статистики в mysql".
В связи с этим вспоминается следующее эссе на тему целевых ниш софта и
зависящих от этого решений по дизайну:
http://web.archive.org/web/20120403172742/http://vydrov.com/index.php/archives/38
http://web.archive.org/web/20120403172742/http://vydrov.com/index.php/archives/73
http://web.archive.org/web/20120403171722/http://vydrov.com/index.php/archives/97
(кто не читал - рекомендую прочитать полностью, считаю, того стоит)
и, в терминах данного автора, sendmail - явно третья категория софта -
с намеренно несокращаемой сложностью для придания веса тем, кто его
использует.
Конкуренты, хоть и зарабатывают на поддержке, таких принципиальных
подходов не применяют (exim явно в категории 2, "для приверед",
postfix частично даже в категории 1).
> > хотя есть любители тонких извращений.
> >
> > И ресурсов, насколько помню, он кушает побольше чем postfix, по крайней
> > мере
> > когда лет 7 назад перевёл один нагруженный сервер с sendmail на postfix
> > разница
> > по мониторингу была заметна, хоть и меньше чем в 2 раза.
>
> А, то есть информация 7-летней давности.
У меня и сейчас разница в ~5 раз в пользу postfix. Так что твоё
ерничанье не по адресу.
-netch-
