| 1.1, fffuuu (?), 14:54, 19/08/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
так что там с sieve, не понятно. ОЧЕНЬ полезное это sieve, используем.
| | |
| |
| 2.3, DeadLoco (ok), 15:32, 19/08/2010 [^] [^^] [^^^] [ответить]
| +/– |
 Раньше нужно было дополнительно ставить костыли довекот-сиве и/или довекот-менеджсиве, а теперь все в одном флаконе. В принципе, и раньше было неплохо, а теперь д/б совсем хорошо.
| | |
| 2.7, sybasesql (ok), 18:00, 19/08/2010 [^] [^^] [^^^] [ответить]
| +/– |
 только пока не вышел Pigeonhole sieve для 2.х ветке не зарелизили, только в гите лежит....
| | |
|
| |
| |
| 3.6, TyLLKAH (?), 16:02, 19/08/2010 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Линус швед из Финляндии.
Managesieve через SSL пускать можно ?
| | |
| |
| 4.8, sybasesql (ok), 18:02, 19/08/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> Managesieve через SSL пускать можно ?
да, именно так и работает. plain text password over ssl:
dovecot: managesieve-login: Login: user=<a@b.c>, method=PLAIN, secured
| | |
|
|
|
| 1.9, Etch (?), 08:01, 20/08/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
Народ, у меня такая ситауция: Есть офис с почтовым сервисом (dovecot1/imap4 + postfix), надо сделать несколько IMAP-ящиков доступными ещё и в удалённом офисе. Просто подключаться к основному серверу через инет не подходит, письма большие и слишком долго загружаются.
Короче надо отзеркалить несколько имап-ящиков на другой сервер так, чтобы все изменения на одном сервере сразу же отражались бы и на другом, а изменения на втором тут же были видны и на первом (или не тут же, но сразу как связь появится). Dovecot2 такое умеет? В какую сторону смотреть? Тут в новости что-то про dsync мельком написано - это оно?
| | |
| |
| |
| 3.11, Etch (?), 09:34, 20/08/2010 [^] [^^] [^^^] [ответить]
| +/– |
А подробней можно? Каким боком тут можно NFS прикрутить? AFAIK - это просто сетевая файловая система, да ещё и медленная, как я слышал.
| | |
| |
| 4.13, samm (?), 10:25, 20/08/2010 [^] [^^] [^^^] [ответить]
| +/– |
>А подробней можно? Каким боком тут можно NFS прикрутить? AFAIK - это
>просто сетевая файловая система, да ещё и медленная, как я слышал.
>
Никаким - вам сказали глупость. НФС крайне плохо себя ведет в случае медленных, да еще и нестабильных линков. Ну и кроме того - трафик будет большим чем совместный доступ к imap shared folder, ага.
| | |
|
|
| 2.12, samm (?), 10:24, 20/08/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
>[оверквотинг удален]
>postfix), надо сделать несколько IMAP-ящиков доступными ещё и в удалённом офисе.
>Просто подключаться к основному серверу через инет не подходит, письма большие
>и слишком долго загружаются.
>
>Короче надо отзеркалить несколько имап-ящиков на другой сервер так, чтобы все изменения
>на одном сервере сразу же отражались бы и на другом, а
>изменения на втором тут же были видны и на первом (или
>не тут же, но сразу как связь появится). Dovecot2 такое умеет?
>В какую сторону смотреть? Тут в новости что-то про dsync мельком
>написано - это оно?
Очевидного решения тут явно нет. Схема которую вы описали - не будет работать нормально.
Вот пример. Офис 1 открывает и модифицирует письмо, которое уже есть в офисе 2. Связи нет. Офис 2 открывает и модифицирует письмо, сохраняет. Связь появилась. Имеем конфликт :)
dsync тут вообще ни при чем - это тип хранилища, вы бы посмотрели довкот вики перед тем как писать, ага. Если канал нереально расширить, то есть несколько вариантов - например работа по имапу (shared folders) не загружая по умолчанию message body. Еще как вариант - офисы с медленным каналом используют веб морду, тот же раундкуб. Ну или мучительно и долго курить дбмейл и реализовывать синхронизацию средствами базы данных (тоже неочевидное решение).
| | |
| |
| 3.14, Александр (??), 10:58, 20/08/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> dsync тут вообще ни при чем - это тип хранилища
Это Вы, уважаемый, путаете. dsync как раз утилита для синхронизации. Другой вопрос, сумеет ли она справиться в такой ситуации, когда на двух хостах одно и то же письмо поправлено независимо. Думаю, собственно, что более новые изменения затрут более старые.
| | |
| 3.15, Etch (?), 11:22, 20/08/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Очевидного решения тут явно нет. Схема которую вы описали - не будет работать нормально.
>
>Вот пример. Офис 1 открывает и модифицирует письмо, которое уже
>есть в офисе 2. Связи нет. Офис 2 открывает и модифицирует письмо,
>сохраняет. Связь появилась. Имеем конфликт :)
Изменение писем не такая уж супернеобходимая фича. Её можно вообще вырубить или при подобных конфликтах создавать две копии письма, т.е. чтобы на обоих серверах были видны обе модификации (а можно ещё и оригинал).
Вообще в нашем случае не важно как будут разрешаться подобные коллизии, поскольку они будут очень редкими и не смертельными.
>dsync тут вообще ни при чем - это тип хранилища, вы бы посмотрели
>довкот вики перед тем как писать, ага.
да я-то посмотрел по диагонали: http://wiki2.dovecot.org/Tools/Dsync и http://wiki2.dovecot.org/Design/Dsync -- вроде на тип хранилища это менее всего похоже...
>Если канал нереально расширить, то есть несколько вариантов - например
>работа по имапу (shared folders) не загружая по умолчанию message body.
Тела сообщений и так сейчас не загружаются, список писем подгружается без особых тормозов. А вот если тыкнуть в тандербёрде по письму с вложениями, тогда уже можно спокойно уходить на обед - к возврату оно как раз догрузится (кроме совсем клинических случаев).
Причём тут "shared folders" я не понял, это же вроде просто папки, расшареные для других юзеров?...
>Еще как вариант - офисы с медленным каналом используют веб морду, тот же раундкуб.
А вот это вариант, хотя бы текст письма можно будет посмотреть. Спасибо, приму к сведению на случай если ничего не выйдет с зеркалированием.
| | |
| |
| 4.25, Александр (??), 17:30, 20/08/2010 [^] [^^] [^^^] [ответить]
| +/– | |
Варианты: на второй хосте поднимайте SMTP-сервер, на нем заводите те же аккаунты, что и на первом, и пропишите на первом что почта для адресатов первого сервера еще и отсылается на имя-юзера@второй.сервер.
Так что, как связь поднимется до второго сервера, SMTP на первом попробует доставить. И юзеры второго будут иметь на своей сервере копии писем.
Другой вариант - делать копию нужной почты в некий (служебный) ящик на первом сервере, его содержимое rsync-ом синхронизировать со служебным ящиком на втором сервере, а уже нужный Вам ящик второго сервера dsync-ать с этим служебным.
Пользя схемы - rsync умеет сжимать трафик, притом неплохо, так что, пока, связь есть, перегонится больше данных. rsync между двумя ящиками напрямую нельзя настраивать, иначе будет много глюков, напр., письмо на сервер "прочитали" - имя файла с письмом изменяется, а rsync может скачать его заново.
В общем, я бы Вам советовал первый вариант. Оно и надежнее, и настраивается проще.
| | |
| |
| 5.39, Etch (?), 15:20, 21/08/2010 [^] [^^] [^^^] [ответить]
| +/– | |
Первый вариант не подходит, т.к. нужна полная синхронность ИМАП-ящиков. Работники должны курсировать между двумя офисами (то там работать, то тут), и не делать двойную работу при этом (удаление ненужных писем). И папка "отправленные" должна тоже синхронизироваться.
Про rsync надо посмотреть, возможно dsync тоже сжимает траффик...
| | |
| |
| 6.40, samm (?), 15:41, 21/08/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Первый вариант не подходит, т.к. нужна полная синхронность ИМАП-ящиков. Работники должны курсировать
>между двумя офисами (то там работать, то тут), и не делать
>двойную работу при этом (удаление ненужных писем). И папка "отправленные" должна
>тоже синхронизироваться.
>
>Про rsync надо посмотреть, возможно dsync тоже сжимает траффик...
Мне кажется, что в вашем случае есть смысл подумать о терминальном решении. Трафик будет при этом крошечный.
| | |
|
|
|
|
| 2.33, SDenis (??), 22:25, 20/08/2010 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
>postfix), надо сделать несколько IMAP-ящиков доступными ещё и в удалённом офисе.
>Просто подключаться к основному серверу через инет не подходит, письма большие
>и слишком долго загружаются.
>
>Короче надо отзеркалить несколько имап-ящиков на другой сервер так, чтобы все изменения
>на одном сервере сразу же отражались бы и на другом, а
>изменения на втором тут же были видны и на первом (или
>не тут же, но сразу как связь появится). Dovecot2 такое умеет?
>В какую сторону смотреть? Тут в новости что-то про dsync мельком
>написано - это оно?
imapsync
| | |
|
| 1.17, Аноним (-), 12:32, 20/08/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Можно посмотреть cyrus-imap, там есть sync_client:
DESCRIPTION
Sync_client is the client side of the replication system. It runs on the client (master) system and connects to the target
(replica) system and generates an appropriate sequence of transactions to synchronize the replica system with the master sys-
tem.
| | |
| |
| 2.18, Etch (?), 13:28, 20/08/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>Можно посмотреть cyrus-imap, там есть sync_client
А вы случайно не в курсе, будет ли он работать с другими IMAP-серверами? Или он привязан исключительно к цирусу?
| | |
| |
| 3.19, Samm (??), 13:55, 20/08/2010 [^] [^^] [^^^] [ответить]
| +/– |
 не будет. Там в настройках имапд цирроза надо куча всего указывать для него (sync_*).
| | |
|
|
| 1.20, Кирилл (??), 14:11, 20/08/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Напрягает следующий момент в 1-м Dovecot: http://wiki.dovecot.org/TimeMovedBackwards
На почтовике стоит ntp сервер, который синхронизируется с другим ntp сервером в сети. Так вот dovecot отваливается (не прощает ;), когда время убегает. Жаль, что во 2-й версии не поправили сей факт.
| | |
| |
| 2.21, аноним (?), 14:25, 20/08/2010 [^] [^^] [^^^] [ответить]
| +/– |
странно как-то у вас время синхронизируется..
с ntp время вообще не должно убегать. там для этого всякие стратумы и пр.
в общем не понятно почему довекот под какой-то баг должны были править.
| | |
| 2.22, nontuko (??), 14:39, 20/08/2010 [^] [^^] [^^^] [ответить]
| +/– |
Довекот валится совершенно правильно в такой ситуации. Решение этой проблемы масса, погуглите. Самый оптимальный, на мой взгляд вариант, запретить ntpd менять время большими скачками.
| | |
| |
| 3.24, TyLLKAH (?), 15:47, 20/08/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Самый оптимальный, на мой взгляд вариант, запретить ntpd менять время большими
>скачками.
Как запретить ? Во FreeBSD был параметр ядра, касаемый максимальной дельты времени, но я его забыл. Да и не то это немного. Надо ntpd как-то настраивать. Мне он тоже однажды настроил время и убил Dovecot
Во втором Dovecot обещали сделать так, чтобы не падал, а ждал, если это возможно. Надеюсь, что сделали
| | |
| |
| 4.27, аноним (?), 18:08, 20/08/2010 [^] [^^] [^^^] [ответить]
| +/– |
это не возможно.
первое что проверяют спамассасины всякие - это время.
так что правьте ntp.
вообще не понятно как это у вас получается.
может там руткит. или "привет" в кроне от бывшего админа?
такая ситуация с постоянным инетом - штатно невозможна.
| | |
| |
| |
| 6.29, TyLLKAH (?), 20:25, 20/08/2010 [^] [^^] [^^^] [ответить]
| +/– | |
Я тоже думал, что невозможно. Для того ntpd и использовал. Оказалось, что возможно. Никаких руткитов и добрых админов - сам всё ставил. Правда за 3 или 4 года года один раз только случилось, но неприятно.
| | |
| |
| |
| |
| 9.37, аноним (?), 00:35, 21/08/2010 [^] [^^] [^^^] [ответить] | +/– | да понял что не при старте но и без точного времени современная почта не тру е... текст свёрнут, показать | | |
|
|
|
|
|
|
|
| 2.26, Александр (??), 17:35, 20/08/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Напрягает следующий момент в 1-м Dovecot: http://wiki.dovecot.org/TimeMovedBackwards
>На почтовике стоит ntp сервер, который синхронизируется с другим ntp сервером в
>сети. Так вот dovecot отваливается (не прощает ;), когда время убегает.
>Жаль, что во 2-й версии не поправили сей факт.
Он совершенно прав, это честно с его стороны.
На крайний случай поставьте по крону watchdog и перезапускате dovecot.
А лучше, конечно, ntpd использовать, а по старту машины делать ntpdate, чтобы время поменялось скачком. Можно грубее сделать - по крону в 4 часа ночи останавливать dovecot, ntpd, запустить ntpdate, разрешив ему на любую величину дергать время, затем обратно запускать ntpd и dovecot. Но - как-то это неаккуратно, что ли.
| | |
| |
| 3.30, TyLLKAH (?), 20:33, 20/08/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>часа ночи останавливать dovecot, ntpd, запустить ntpdate, разрешив ему на любую
ntpdate лучше вообше не использовать - dovecot может прямо на старте помереть. А в случае с ntpd его можно прописать в REQUIRE в dovecotовский скрипт запуска.
| | |
| |
| 4.32, аноним (?), 22:16, 20/08/2010 [^] [^^] [^^^] [ответить]
| +/– |
в предлагаемом сценарии - глупости.
и вообще довекот меня никогда не подводил. неубиваемый практически.
| | |
| |
| 5.35, TyLLKAH (?), 23:20, 20/08/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>в предлагаемом сценарии - глупости.
Не конструктивно. Я не чувствую себя уязвлённым. Где конкретно глупости.
если в rc.conf ntpd_sync_on_start="YES"
то в dovecot
# REQUIRE: LOGIN mysql ntpd
и sleep
Это FreeBSD если что. Так в чём здесь глупость ?
| | |
| |
| 6.36, аноним (?), 00:31, 21/08/2010 [^] [^^] [^^^] [ответить]
| +/– |
вот в этом
>ntpdate лучше вообше не использовать - dovecot может прямо на старте помереть.
не коррелирует с этим:
остановить довекот и нтпд, дернуть время нтпдэйт, запустить нтпд и довекот.
| | |
|
|
|
|
|
| 1.41, Аноним (-), 03:05, 23/08/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Короче DOVECOT всем хороший кроме бага со временем. Подчеркну, что это именно БАГ. Система работающая с сообщениями не должна валиться ни при каких обстоятельствах - хоть на сервере "потоп".
P.S. Вспоминайте лозунг системы "КАЖДАЯ ХЕРНЯ ДЕЛАЕТ СВОЕ ДЕЛО!".
| | |
| |
| 2.42, Зилибоба (ok), 13:39, 23/08/2010 [^] [^^] [^^^] [ответить]
| +/– |
 Ну, может такое поведение описано в спеках? =) И потом, баг - всегда может оказаться фичей и наоборот... Все зависит от точки зрения.
| | |
|
|
